Hi,
I am trying to test my workflow behavior in case of an activity timeout. In my workflow code, I am checking if exception.getCause() instanceof TimeoutFailure and in this case I want to continue the workflow as new.
When testing this behavior, I tried to mock my activity call to throw new TimeoutFailure(...) and throw new ActivityFailure(..., new TimeoutFailure(...)) but neither of these seem to be executing the catch block. On top of that, the execution of the try block also appears to be incomplete so I assume that throwing a TimeoutFailure is intended only for temporal code. I have a couple of questions here:
How to mock the activity timeout behavior for different timeout types
What is the recommended way to verify that the workflow has been continued as new at some point in its execution history
I think that for timeouts, best way is to use the time skipping server and sleep for longer than your configured start to close. Works reliably!
As for the second point, I’d figure reading the execution history and asserting a continue as new event exists after the workflow finishes. You might have to traverse the links, though. I am not sure.
Using Thread.sleep on activity invocation works but it cannot be timeskipped. Also in my case, the activity heartbeat timeout is a bit high and the start-to-close timeout too. I am trying to find a way to inject an activity spy with custom activity options into the workflow in order to trigger the timeout faster.
I tried to create the activity stub in my test with my custom options using TestActivityStub and to register it into the worker. Still the workflow is creating its own activity with the default options used inside the workflow code. Is there a way to work around that
You should not use Thread.sleep, but Workflow.sleep, then it will be timeskipped. Thread.sleep is not committed to event history, and can lead to non-determinism