A Scenario That Fails Safely

Ne işe yarar İngilizce

Every scenario has modules that must never run twice — a payment, a message, a write to a ledger. This covers error handlers and how to make a retry safe around exactly those.

Becerinin kendisi Kopyala

A scenario is easy to build and quiet when it breaks. Decide the failure
behaviour per module before adding the next one.

For every module, answer:
- **What if it runs twice?** Webhooks re-fire and scenarios retry. Any module
  that creates, charges, sends or posts needs a Search-before-Create, or a
  deduplication key stored somewhere the retry can see it. Without one, a retry
  sends a second invoice.
- **What if it fails halfway?** If modules 1–3 wrote and module 4 failed, the
  record is half-made. Either make the last module the only one that commits,
  or attach a rollback route.

Then, concretely:
- Attach an **error handler route** to every module that touches an external
  service. The default is "scenario stops", and a stopped scenario is silent.
- Use `Break` with a retry interval for transient failures and `Commit`/
  `Rollback` for anything transactional. `Ignore` is almost never right — it
  converts a failure into missing data.
- Route errors to somewhere a human reads. Make's own notification goes to the
  account owner's email and is routinely filtered.
- Turn on **sequential processing** for anything writing to the same record.
  Parallel bundles hitting one row is the bug that only shows up under load.

Nasıl kurulur Kopyala

1. Open the tool and start a new conversation, project or template.
2. Paste the text below wherever the tool keeps standing instructions
   — usually called system prompt, instructions, or persona.
3. Save it so it applies to every run rather than a single message.

Sende işe yaradı mı?

Nereden geldi