Reconcile duplicate, late and missing callbacks with a local ledger

01Prepare environment and inputs

1. Download the complete kit and use Node.js. The recorded run used Node v24.18.0 with only its built-in HTTP, filesystem and crypto modules.
2. Read fixture.json: local-A receives a success event twice and then a late processing event; local-B receives no callback and is recovered by one local status request.
3. Choose a fresh output directory. The server binds an ephemeral port on 127.0.0.1, accepts only the two fixture task IDs and closes in finally. No provider credentials are used.

02Run the recipe

Run command

node run-recipe.mjs --out ./my-run

1. Bind callbacks to a known task

   Run the command from the unzipped kit. Before accepting an event, the receiver checks the task ID, event ID and its deliberately small processing/succeeded state vocabulary. The fixture rejects unknown tasks and an invented state with HTTP 400. These validation rules are local examples, not a provider payload specification.

2. Apply each event once

   Read ledger.json after the replay. evt-1 changes local-A to succeeded; replaying the same event ID is recorded as duplicate. The event set is a fixture store in memory. A deployed receiver would need durable event uniqueness and an atomic state update appropriate to its own database.

3. Protect the completed state

   The distinct evt-2 arrives late with processing. Its lower state rank is logged as stale, leaving local-A succeeded. This two-state policy demonstrates a terminal guard; it does not define cancellation, failure, retry or conflicting-terminal rules for a real API.

4. Reconcile the absent callback

   local-B remains processing until GET /status/local-B returns its matching task ID and succeeded state. Update the same ledger entry and verify one poll, zero /generate requests and a closed local server. The negative receipt also checks a poll result bound to the wrong task.

03Check the result

• All ten named checks pass and the two executing script hashes match before and after the run.
• The initial terminal event is applied and its exact event ID replay is marked duplicate.
• The late processing event is marked stale and local-A remains succeeded.
• An unknown task and an invented state both return HTTP 400.
• local-B is pending before reconciliation and succeeded after one task-bound local poll.
• ledger.json reports zero generation requests and the loopback server is closed.

04Troubleshoot and deliver

Keep the replay ledger and receipts as evidence of this local reducer. Adapting it to a real service requires that service’s documented callback support, verification rules and durable storage; this kit makes no customer Webhook commitment.

05Download scripts and fixtures

• Original task-specific local-fixture diagram ↓
• Complete runnable kit with original inputs and real receipts ↓
• Task-specific standard-library fixture runner ↓
• Bounded local execution and receipt helpers ↓
• English execution and acceptance guide ↓
• English machine-readable task brief ↓
• Chinese execution and acceptance guide ↓
• Chinese machine-readable task brief ↓
• Actual complete passing execution receipt ↓
• Actual expected-rejection receipt ↓
• Named task-specific check results ↓
• SHA-256 inventory for distributed files ↓
• Recorded fixture: fixture.json ↓
• Recorded fixture: ledger.json ↓