Workflow tasks can fail for various reasons. Note that some of these reasons can only originate from the server, and some of them can only originate from the SDK/worker.
public enum WorkflowTaskFailedCause : int
The worker encountered a mismatch while replaying history between what was expected, and what the workflow code actually did.
Starting a new activity would cause this workflow to exceed its limit of pending activities that we track.
We send the below error codes to users when their requests would violate a size constraint of their workflow. We do this to ensure that the state of their workflow does not become too large because that can cause severe performance degradation. You can modify the thresholds for each of these errors within your dynamic config.
Spawning a new child workflow would cause this workflow to exceed its limit of pending child workflows.
Similarly, we have a buffer of pending requests to cancel other workflows. We return this error when our capacity for pending cancel requests is already reached.
A workflow has a buffer of signals that have not yet reached their destination. We return this error when sending a new signal would exceed the capacity of this buffer.
The worker wishes to fail the task and have the next one be generated on a normal, not sticky
queue. Generally workers should prefer to use the explicit
Between starting and completing the workflow task (with a workflow completion command), some new command (like a signal) was processed into workflow history. The outstanding task will be failed with this reason, and a worker must pick up a new task.