The following post on stack-overflow recommends to use a queue internal to a workflow to prevent certain raceconditions while using signalWithStart and in general enforce FIFO execution of signals.
Is this still a good recommendation or did the internals of the sdk in the meanwhile change in such a way the mentioned best practices are no longer needed?
It depends on the use case. If you want to process many signals of the same type in order, then using a queue is preferable.
What is your use case?
Hi @maxim, thank you for responding so quickly.
We’re aspiring to use Temporal to model the lifecycle of a customer facing shopping basket. This will heavily depend on human driven signals coming from our app & web backends. Currently these baskets can live months (if not years) depending if users prolong their lifespan by mutating them before they reach their end-of-life. We foresee that we need to manage the event history size by running ContinueAsNew as the history size can become quite large. The order of signals matter as certain products cannot be added unless other products have been added due to business rules, for example promotions. Due to bot activity, scalpers and other automation the amount of signals will be more than 5 per second in certain cases.
Based on the above, do you believe we need to take precautions and internally enforce the completion of signals to be guaranteed to be in order by using an internal queue?
Using a queue (or multiple queues) in this case is appropriate.