Queuing actions with unique parallelism limiting semantics
How would I go about ensuring concurrency semantics with actions that are more complex than what workpools and workflows currently provide? For example, sequentially executing some actions enqueued by a specific user, because these actions could change state relating to the user and put it in a state that other actions are not allowed to run in.
I've implemented a queue on top of workflows for this purpose, but considering how complex the workpool implementation is, I can't imagine it's actually very sound. I haven't even touched back pressure yet.
Given my requirements, and the highly specific implementation of these concurrency related components, do I have no choice but to entirely DIY it?
Is this a code smell?
1 Reply
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!