I have question about the behaviour that happens when a workflow attempts to run activity that is not registered with a worker. Why is the default behaviour to have the activity fail and retry rather than hanging the workflow. It does not make sense for me to retry the activity if I know the next retry is also gonna fail since the activity would still be not registered and I did not do anything to fix this.
Why is this the default behaviour?
Workflows can run as long as needed. So many failures considered permanent in a traditional RPC world can be treated as temporary in the Temporal world. You can fix the activity worker by adding the activity, and the workflow will complete. This situation frequently arises during rolling deployments when only the new worker version contains the activity.
Hello Maxim, thanks for you reply.
I understand this but what benefit would we get by having the activity retry if it is not reigstered to a worker instead of having the workflow hang awaiting a fix like the behaviour when there is an undeterminstic error. Maybe we should not attempt to run the activity altogether if it not registered.
If the activity has a fixed number of retries let’s say 3, and the activity failed the first time because it’s not registered chances are it will also fail the other times and the workflow would probably fail since we did not have time to fix the issue.
A solution for that would be to keep the default infinite retries for the activity but it is not something we want to.
We have plans to introduce “activity pause” feature. It would pause activity retries until explicitly unpaused.