It is difficult to write this eloquently, but I am looking for suggestions on how to handle a workflow which has a need for retries outside of the atomic “activity” unit provided by temporal. I also want to keep my activities modular.
My workflow is simplified in the diagram above, but essentially several tasks make up a DAG.
- We must first fetch an identifier for an Object (ID). [fetchId]
- With ID, fetch the Object status from an external dependency. [fetchStatus]
- We also want to determine the state of our Object on our database. [getRecord]
- If our Object state has changed, persist. [record]
- While Object status is NOT complete, GOTO 2.
Since step 5 is at a higher level of abstraction than the activities, I have implemented my own retry logic in the workflow which uses Workflow.sleep if our status is not complete. However, this code was not clean. I would prefer to combine the entire
repeatable block (2-5) into a single activity.
The problem is that my retries for each activity and the overall block
repeatable need to vary heavily. Essentially, this is a poller which will have much larger backoff periods than the activities which will have limited backoff for dependency failures, etc.
I thought about using a child workflow, but would the best approach for that be to have my parent workflow implement an activity which invokes the
repeatable block as a child workflow, then throw if the status is not complete (allowing the parent activity’s retry options to kick in)?