Oh, you want to run a single workflow for each request, but ensure that requests for a particular user are executed one at a time?
There isn’t actually a cost to having a workflow waiting for a signal for a long time. The workflow execution history is simply stored in the database and replayed if needed when a new signal comes in. It doesn’t consume worker resources long term.
I think we would want to use continueAsNew to avoid having the workflow execution history grow too large.
@maxim is this what you’d recommend? As I understand it, the requirements are:
- each incoming request should be processed in a workflow
- for a particular user ID, processing of requests need to occur one at a time
- requests for different user IDs can be processed in parallel
One solution might be to use signal-with-start with the workflow ID based on the user ID. This ensures that all requests for a particular user ID are routed to the same workflow. The workflow would receive the requests as signals and execute them one at a time. It would need to call continueAsNew periodically to avoid growing the workflow history too much.
To avoid having the workflow running indefinitely (to avoid cluttering the UI if nothing else), as @ilya1 suggests the workflow could set a timer and stop executing if no requests have been received within a timeout. If a new request does come in the workflow would be started with signal-with-start as usual.
What do you think?