Reputation: 2001
Consider the following scenario:
My orchestrator O
starts, and calls sub-orchestrator S
. S
succeeds in processing activities A1
and A2
but fails in A3
. I have automatic retries on A3
, but no luck (the webservice i'm calling is giving a 404). No problem, I catch the exception and perform cleanup for A1
and A2
.
Eventually I need to retry the process. What is the proper way to do this?
My current approach was going to be, writing a message to a custom poison queue with a visibility delay, and then having another AZ func that pulls from this queue, and restarts the sub-orchestrator.
It would also be ideal if i could restart the same sub-orchestrator with the same invocation ID. Theoretically this could save me from having to redo A1
and A2
as well as their cleanup!
Is this the correct line of thinking, or am I misusing durable functions?
Upvotes: 0
Views: 1220
Reputation: 6647
There is an API - Rewind Instances (Preview) - that I believe you can use for this. You need the orchestration instance ID to use this.
You should be able to query for failed instances, filter based on custom status and then call rewind on them.
Upvotes: 1