I’ve been bitten a couple of times by making changes to a workflow that caused a NonDeterministicException. I have a use case where when this is thrown, I just want the workflow to fail, so that I can trigger a new workflow with the same inputs on the new version. Basically the desired behavior is when NonDeterministicException just give up on the workflow.
Is there a kosher way of doing this? For example, can I catch NonDeterministicException and just mark it as a NonRetryableException?
NonDeterministicException cannot be caught inside your workflow code, but
you could set it to fail workflow execution via WorkflowImplementationOptions, for example:
This should fail your workflow in case of NonDeterministicException.
Imo still the default behavior of blocking workflow task allowing you to fix the issue (using versioning for example) might be a better approach than failing the workflow execution.
A WorkflowPanicPolicy that restarts workflows on nondeterministic error might be a good addition. Do you think that is something I could create a github issue for?
My use-case is this:
All workflows that we write at my company are restartable. i.e, we maintain our own checkpoints so that when a workflow is restarted, it continues from where it left off. We tend not to use workflow versioning since that makes the workflow code hard to read. Hence, an option to automatically restart workflows (a fixed number of times) on nondeterministic error would be super helpful.
@mvp We have a workaround without any changes to the temporal.
With WorkflowPanicPolicy set to worker.FailWorkflow
And RetryPolicy set to some value when starting a workflow allows us to restart the workflow when workflow encounters non-deterministic panics.
But there are a few caveats:
Any panic will result in workflow restarting
Any real errors returning from the workflow to terminate the workflow must be wrapped with temporal.NewNonRetyableError
Workflow retry does not seem to replay this signals (which we want for our use case)
Commenting on this thread because I think this is the closest thing;
Is there an equivalent option for TypeScript? Especially for testing?
One thing I noticed - and correct me if I’m wrong, is that the ergonomics of the TypeScript workflow testing is pretty bad on failures. Specifically, if it fails for these “system” reasons - either missing activity definition or an uncaught exception in the workflow code, then the workflow is stuck in an infinite retry loop, so the error surfaces in timing out.
I would rather want these failures to fail immediately. I believe that go’s WorkflowPanicPolicy would handle the case I describe, but I don’t think there’s a similar option on the TypeScript side.