As I’m fixing issues in one of our workflows (thank you for your help!), I’ve come to a case I’m not sure how to properly handle with the Java SDK.
The workflow I’m working on has to continue as new and propagate the workflow state when it gets enough signals. The case I’m not sure how to handle happens when the workflow gets several signals at the same time. If one of the signal processors decides to call trigger the continue-as-new command (via Workflow.newContinueAsNewStub), it looks like any pending signals are lost - my signal handlers won’t get called for them in the scope of the existing workflow and they won’t get re-scheduled for the continued-as-new workflow.
I feel like I’m missing something important here. I’ve found this paragraph in the Go SDK docs:
To prevent Signal loss, be sure to perform an asynchronous drain on the Signal channel. Failure to do so can result in buffered Signals being ignored and lost.
however, I can’t find a matching mechanism in the Java SDK.
Thank you, @tihomir! Are there any corner cases with using newContinueAsNewStub with Java SDK? I seem to be losing some signals when a signal handler decides to trigger a continue-as-new but there are still some more signals left to be processed.
Signal handlers are always called before the main workflow thread is unblocked. So they are guaranteed to be invoked before the ContinueAsNew is called.
But if a signal handler blocks on a Temporal API then the main thread can be invoked without waiting for the signal handler to complete.
Another possibility is when a signal is buffered in some queue variable, and that queue is not properly drained similarly to Go.