failure-cases

Failure Cases

Documented failure modes with root cause and the fix that worked. This is the evidence base the rest of the wiki (and, eventually, the repair engine and the self-improvement loop) is built on.

A failure case is not the same as a bug report. It captures:

• what was observed
• what the actual root cause turned out to be (often different from the first guess)
• the fix that resolved it
• the pattern or rule that would have prevented it

Good failure cases turn into repair rules and shape the patterns library.

Entry shape

## <Short name>

- **Framework:** n8n / Dify / ...
- **First observed:** YYYY-MM-DD
- **Symptom:** what the user saw
- **Root cause:** what it actually was
- **Fix:** what resolved it
- **Generalises to:** pattern / repair-rule references

Seed cases

Webhook double-fires when downstream call is slow

• Framework: n8n
• First observed: 2024-08-12 (illustrative; reconstructed from a common community report)
• Symptom: Stripe payment_intent.succeeded events occasionally produced two orders in the downstream system.
• Root cause: the workflow only responded 200 to Stripe after the order-creation HTTP call returned. Slow runs (>10s) triggered Stripe's retry, which arrived before the first run finished. Both runs created an order because there was no idempotency check.
• Fix: added the idempotent webhook ingress pattern keyed on Stripe's event.id, and moved the Respond to Webhook node to the start of the side-effecting branch (immediate 200).
• Generalises to: n8n-webhook-missing-response, idempotent webhook pattern.

HTTP node hung for hours on a misbehaving vendor

• Framework: n8n
• First observed: 2024-11-03 (illustrative)
• Symptom: scheduled workflow stopped producing new runs. Queue was empty but executor was at 100% slot usage.
• Root cause: one of the upstream APIs started accepting connections but never responding. The HTTP node had no timeout set, so every scheduled run accumulated and held a worker slot indefinitely.
• Fix: set options.timeout: 30000 on the HTTP node and wrapped the call with bounded retry.
• Generalises to: n8n-http-missing-timeout.

LLM output passed downstream without schema check

• Framework: n8n + OpenAI / Anthropic
• First observed: 2025-02-09 (illustrative)
• Symptom: downstream Postgres insert failed intermittently with column "category" is null.
• Root cause: the LLM was asked to return JSON with a category field. About 1% of the time it returned valid JSON without that field. The workflow trusted the parse and forwarded the dict as-is.
• Fix: added a JSON-schema validation step between the LLM and the database write. Invalid outputs route to a "needs review" branch instead of failing the workflow.
• Generalises to: validate the shape of LLM output, not just whether parsing succeeded.

---

These cases are illustrative. They are based on common patterns in the n8n community but are not tied to specific user incidents. Real cases gathered from the audit and validation pipeline will be added with concrete workflow references over time.