The workflow fails to drain the signal channel before calling continue as new. Temporal guarantees that if a channel is fully drained using async receive and no blocking operations are executed after that, no signal is lost. But your code calls activities after draining the signals. So all signals that are received during the activity execution will be ignored.
To fellow space travelers landing here in future, I have modified the code according to @maxims suggestions. I now get the expected behavior. Although draining signals on exit, is documented, it was not immediately obvious how to restart with the missed history. After watching the very informative 3hour workshop on YT, state in workflow execution is a lot clearer now. (Temporal Intro Workshop with Go (3 hrs with Q&A) - MĂĄrk SĂĄgi-KazĂĄr (Banzai Cloud/Cisco) - YouTube) Thanks @maxim for your assistance and a great product!
3 Likes
Thanks for the well-illustrated question, @Jeremy_Convoy.
One thing Iâm confused about, is the whether the âbatchâ workflow would end up losing signals. If I understand correctly, during the initial period of time, it accumulates requests to be sent. Then upon deadline or a certain number of requests, it makes a batch request. At that point the workflow still exists (so âStartWithSignalâ wonât start a new one) but the request train left the station.
What can the âbatchâ workflow do with all those âoverflowâ signals? Can they be pushed into the next execution? We canât just ignore them since the caller relied on the âat least onceâ delivery of the signal.