Durable workflows with retries

What you get

• Steps that retry on their own
• Runs that resume after the last finished step
• Events sent from your app, with duplicate protection
• Pauses and waits of hours or days
• Failed runs held for replay
• An alert when a workflow fails three times in a row

How it works

Your app sends an event, such as a new order, to its own queue. A workflow listed in the app's whisk.yaml picks it up and runs it as a series of named steps. The result of each step is saved, so a finished step never runs twice.

When a step fails, it is retried after a short wait, then a longer one. If an outside system is down for an hour, the run waits and carries on from that step. A run that still fails is held and can be replayed once the cause is fixed. Three failures in a row send one alert.

Workflows run on Inngest, the open-source workflow engine, unchanged. Your coding agent writes standard Inngest code, and every run appears on its workflow diagram. The same engine runs scheduled jobs.

Example

A plumbing merchant turns each web order into a sales order in its accounting system and a pick list for the warehouse. When the accounting system's API times out, only that step is retried, so the order is never entered twice.

For your coding agent

functions:
  - name: order-to-sales-order
    event: order.placed
    graph: workflows/order-to-sales-order.graph.yaml
    retries: 5

The app sends order.placed with a POST to WHISK_QUEUE_URL. Follow a run with whisk runs show <run id> and replay a held one with whisk runs replay <run id>. Every field is in the whisk.yaml reference.