# n8n POST timeout and idempotency experiment

This directory contains the frozen protocol and, after a valid run, the complete public evidence for the `n8n-timeout-idempotency` experiment.

## Question

If an HTTP service commits a POST side effect before its response is delayed beyond the n8n client timeout, does retrying recover the workflow, and how many records are created with and without server-enforced idempotency?

## Frozen protocol

- n8n image: `n8nio/n8n:2.30.5`
- HTTP Request timeout: 300 ms
- delayed fixture response: 800 ms
- retry branches: at most 3 total attempts, 100 ms between attempts
- scenarios: immediate response, one delayed response, two delayed responses, and every response delayed
- strategies: no retry/no key, retry/no key, retry with an `Idempotency-Key`
- repetitions: 10 per scenario, 40 workflow runs, 120 strategy observations

The local fixture creates a record before applying the response delay. The idempotent branch is deduplicated by the fixture itself: repeated requests with the same key return the original record and do not create another one. Merely sending a header to a service that does not enforce it would not provide this protection.

## Expected outcomes

| Scenario | No retry | Retry, no key | Retry, enforced key |
| --- | --- | --- | --- |
| immediate 200 | success / 1 request / 1 record | success / 1 / 1 | success / 1 / 1 |
| first response delayed | failure / 1 / 1 | success / 2 / 2 | success / 2 / 1 |
| first two responses delayed | failure / 1 / 1 | success / 3 / 3 | success / 3 / 1 |
| every response delayed | failure / 1 / 1 | failure / 3 / 3 | failure / 3 / 1 |

## Evidence files

- `manifest.json`: protocol, pinned image, run timestamps and validation state
- `workflow.json`: importable n8n workflow with the three strategies
- `runs.csv`: one row per strategy observation
- `requests.csv`: every request observed by the fixture
- `records.csv`: every committed side effect and its idempotency key state
- `samples.json`: first normalized observation from every scenario and strategy
- `summary.json`: aggregates, protocol mismatches, conclusion and limitations

## Boundaries

This is a deterministic local HTTP fixture, not a claim about every API. It models the important but specific case where the server commits before the client sees a response. Real providers differ in their timeout, idempotency retention, request hashing, conflict handling and status lookup contracts. The experiment does not test payment systems, network partitions, queue mode, concurrent clients or vendor-specific retry headers.