Sample diagnostic: duplicated Pine webhook action
This fictional incident shows how one Pine alert is reconciled across the alert event, HTTP receipts and the recorded downstream outcome. All identifiers, times and systems are invented.
Finding
One logical alert produced two actions because retry handling was not idempotent.
First divergence
The duplicate receipt passed the action-creation boundary.
Smallest next step
Deduplicate on a stable event ID before side effects occur.
1. Frozen event timeline
Swipe the table sideways to read the full timeline.
| UTC time | Observed event | Evidence source |
|---|---|---|
| 14:30:00.000 | Bar closes; Pine condition becomes true | TradingView |
| 14:30:00.184 | Alert event emitted with event_id EVT-1042 | TradingView |
| 14:30:00.492 | First HTTP 200 receipt recorded | Webhook gateway |
| 14:30:01.037 | Retry received with the same event_id | Webhook gateway |
| 14:30:01.091 | Second downstream action created | Synthetic executor |
Reconciliation result
The alert source emitted one logical event. The gateway recorded two receipts with the same event ID, and both receipts crossed the side-effect boundary. The first proven divergence is therefore downstream of HTTP receipt and upstream of action creation—not in the Pine condition itself.
2. Acceptance matrix
Swipe the table sideways to read every case.
| Scenario | Input | Expected behaviour | Class |
|---|---|---|---|
| First valid event | New event_id and valid payload | Record one receipt and create one downstream action | Positive |
| Transport retry | Same event_id received again | Return success without creating another action | Boundary |
| Changed event | New event_id on a later closed bar | Create exactly one new action | Positive |
| Missing identifier | Payload has no stable event_id | Reject safely and preserve the raw receipt for review | Negative |
Run the matching test fixture
The public, dependency-free Node fixture implements the receiver boundary described here and includes seven deterministic tests for first receipt, retry, payload conflict, missing identifier, later event, concurrent retry and uncertain downstream failure.
Inspect code and tests on GitHub3. Bounded recommendation
- Define a stable event ID from the alert source or at the trusted ingress boundary.
- Persist the ID before any order, notification or other side effect is created.
- Return the same successful acknowledgement for a retry without repeating the action.
- Rerun the four frozen cases and retain the receipt-to-outcome evidence.
Software-engineering example only. It is not trading advice and does not represent a client, account, execution venue or performance result.