# n8n batch item failure experiment

Status: `VERIFIED`.

The frozen protocol executes two importable workflows against a local deterministic HTTP fixture. Each workflow generates five items. The fixture returns HTTP 500 for item 1, 3, 5, or no item. The runner repeats every scenario five times for each strategy.

- `workflow-stop.json`: default stop-on-error behavior.
- `workflow-continue.json`: the HTTP Request node has `continueOnFail: true`.
- The fixture records every request before responding, so a failed n8n execution cannot erase evidence of already-sent side effects.

The frozen run completed 40 workflow executions and produced 200 server-side request records with zero validation failures.

Observed result:

- Both strategies sent all five HTTP requests, including when item 1 or item 3 returned HTTP 500.
- Default stop-on-error marked all 15 failure-scenario runs as failed and did not run the downstream node.
- Continue-on-fail marked the same 15 failure-scenario runs as successful, ran the downstream node, and passed five output items including one error item.
- Stop-on-error therefore stopped the workflow after the HTTP Request node finished its five-item batch; it did not prevent later input items from reaching the server.

The one-repetition diagnostic run initially expected requests to stop at the failing item. Two protocol assertions rejected that hypothesis. Those diagnostic artifacts are retained outside the public evidence package; the full run used the corrected, observable protocol and passed all validations.