Mark
Mark

Reputation: 2001

Retrying Durable Function activity/orchastrator later

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

Answers (1)

PramodValavala
PramodValavala

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

Related Questions