n8n approval webhooks: duplicate callbacks and recovery.

Download the complete recovery lab and open the reproduction instructions. On a Linux host with Python 3 and Docker, review the source and run sudo python3 run-lab.py from the extracted directory. A Linux user with UID 1000 and Docker access can run without sudo. The recorded host was ARM64 Linux; other host platforms were not evaluated.

The runner creates two disposable containers on a private network: n8n and a synthetic approval/destination fixture. It generates temporary header credentials, imports and publishes the three-node workflow inside that disposable instance, sends the test callbacks, exports results and removes the lab containers and network. It exposes no host port and uses separate state directories. Review the named-resource cleanup before running it.

Importing the workflow JSON alone is insufficient. The workflow needs the private fixture, seeded proposals and matching lab credentials. Keep it in the disposable lab; the fixed reviewer and synthetic writer are teaching components.

The n8n Webhook node supports authentication at the callback route. This lab uses Header Auth for one fixed reviewer credential. Its HTTP Request node maps the credential to reviewer-a; incoming actor or reviewer body fields do not choose the identity.

Missing and incorrect credentials were denied. A valid credential also failed to approve a proposal assigned to another reviewer. Supplying that other reviewer's name in the request body did not change the result. Authentication answers who can call; proposal ownership answers who can make this particular decision.

A real review portal needs its own user sessions, reviewer assignments and access policy. This lab's single credential is sufficient for its measured boundary but does not provide those capabilities. The fixture source shows where ownership, version and payload are checked.

Bind the approval to the proposal identifier, version, target record and exact note. The fixture hashes that tuple, compares it with the stored proposal and rejects a changed tuple. The server controls the deadline; an incoming timestamp cannot extend an expired review.

The decision transaction uses SQLite BEGIN IMMEDIATE and a unique decision row for each proposal. Ten concurrent approval requests produced one decision and one destination receipt. A concurrent approve/reject pair also produced one terminal decision. The first valid decision committed by the fixture wins; the test accepts either winner and verifies the matching destination effect.

This concurrency test used one n8n process and one fixture process. It does not evaluate queue mode, multiple workers or competing database processes. Adapt the transaction and ownership rules to the actual database rather than assuming this result transfers unchanged to another topology.

Approval and delivery have separate states. The approval transaction records an approved proposal with a pending delivery before calling the destination. The synthetic writer checks a stable action identifier for an existing receipt before creating an entry. Its receipt and target-version change commit in the same destination transaction.

In the lost-response scenario, the fixture committed the write and deliberately returned HTTP 504. The destination had one receipt while the delivery record remained pending. After the process restart, the harness sent the same callback once. The writer found the original receipt, returned reconciled and marked delivery complete. Its receipt identifier stayed unchanged.

HTTP 504 here is an injected failure response, not a measured external-provider network timeout. The fixture owns its receipt database and can enforce the unique action identifier. Before adapting this pattern to a CRM, establish which destination reference can be read back and what its write API guarantees. An unknown write result requires reconciliation; repeated execution alone cannot establish that another write is safe.

The harness stopped both isolated containers with SIGKILL after the initial callback responses had completed. It then started them with the same database mounts. One proposal was still pending. Two other proposals were approved with pending delivery: one had failed before a write, and the other had a committed receipt with a failed response.

The three post-restart checks passed. The pending proposal could still be approved. The before-write failure produced one receipt after replay. The lost-response case reused its existing receipt. The source and dated result file expose the pre-restart records alongside the final counts.

Recovery was explicitly initiated by the test harness. The kit includes no autonomous recovery scheduler. It also does not test a process kill during the destination transaction or a resumed Wait execution. The Wait node's timeout and resumption settings are a separate transport choice. An expired review must still be rejected before any action is authorized.

Recorded on 5 October 2026 with n8n 2.35.4 and Node 24.18.1. All 18 scenario assertions passed. The run retained 30 n8n execution records; the two injected destination failures are expected failed executions. A passing scenario means the resulting decision and receipt count matched the test, not that every webhook execution succeeded.

Download the assertion and callback driver, container runner, raw results and source checksums. Reproduction overwrites the extracted local result file with the new run's timestamps. Compare scenario outcomes and evidence, not execution identifiers across separate instances.

Keep the existing 13-case human approval lab for decisions inside one execution. Use this companion for the separate callback and recovery boundary. Neither fixture establishes production customer outcomes.

A deployed integration still needs real reviewer sessions, a destination adapter, durable state appropriate to its workers, recovery ownership and checks under its actual load. Record those results in the production acceptance worksheet; its rows remain untested until your implementation supplies evidence. The new lab's measured results do not complete that worksheet.

If an approval protects a website-to-CRM handoff, bring the exact proposed change, the reviewer rule and a destination receipt example to a workflow implementation review. Use the migration checklist if the change also replaces an existing Zap.