Can Query be used to fetch the state of workflow in near real time?

Hi,

I am new to temporal. Let’s say there are millions of workflows running or dormant in temporal. Each workflow has some enum X which is updated via some signals in the workflow.
Can the Query method be wrapped as API to expose the enum state X of a workflow, directly to the end user, given there are 1000s of requests per second? Can temporal serve responses to 1000s of queries per second in real time?

Also, a different question- Can new query methods be added to a workflow without versioning?

It can be if the query request rate to a single workflow is not too high. Temporal scales out with the number of workflow executions.

Thanks for taking out time.
Follow up- What should the rate limit be, per workflow, for this to work? Are there any better alternatives to serve this use case?

I think you don’t want to go over a few requests per second. What is your use case? Frequent polling through a query is usually an anti-pattern.

You can add query methods without versioning.

Use Case- Each User has a respective workflow running with a enum State X with values {A, B , C}. Would like to expose this X value to his/her app dashboard. Query rate per single workflow would be worst case 1 per 15 secs.

This sounds like a reasonable use for the query. In the future, we might add the long poll query that would block a request until a state change to reduce churn.

Hi @maxim

Just come across this thread and was looking to see if there was any option to long poll queries. This thread is almost 3 years old, wondering if this feature would be implemented any time soon?

Thanks,
Jay.

We haven’t started work on this feature. It is still part of our long term plans but no ETA.

Since the last post, we have implemented the update feature that uses a long poll to wait for a result. It is not the same as a query, as it allows mutating workflow state and adds events to the history. But this is useful for scenarios when a user (or any other system) makes a request and needs to wait for the workflow to reach a certain state before replying.