dhiaayachi
commented
2 months ago Thank you for reporting this potential feature request! We appreciate your feedback.
It's interesting to see how the event history is currently discarded after handling a query task. This does indeed seem wasteful for query-heavy workflows with large history and a codec involved.
While directly adding sticky attributes to RespondQueryTaskCompletedRequest might not be the most optimal solution, here are some potential workarounds you can consider:
- Use a local cache: Cache the event history locally on the worker to handle subsequent queries more efficiently. This approach requires careful management of cache size and eviction strategies to prevent memory issues.
- Employ Query-based caching: Instead of caching the entire event history, cache the results of specific queries. This approach can be more memory-efficient and may reduce latency for repeated queries.
- Optimize your workflow: Consider restructuring your workflow to reduce the amount of data that needs to be processed for each query. This might involve breaking down the workflow into smaller steps or using more efficient data structures to store your state.
We understand the importance of optimizing query performance for query-heavy workflows, and we'll continue to explore ways to improve the handling of event history in the future.
Is your feature request related to a problem? Please describe. Currently, if a query task is delivered to a worker through a normal queue, the event history is discarded after handling the query task since RespondQueryTaskCompletedRequest does not carry any sticky attributes.
For query heavy workflows with large history, especially when codec is involved, discarding the payload seems to be wasteful, and paying latency penalty unnecessarily.
Describe the solution you'd like I'd like to see sticky attributes to be added to RespondQueryTaskCompletedRequest or in any other ways to cache the event history on worker in order to handle subsequent queries more efficiently.