## TL;DR
The crash wastes the whole run because results are written at the end. Chunk the 5,000 lines by PO or vendor into groups that each complete in minutes, write each chunk's match results and exceptions immediately, and track chunk completion so a crash or timeout resumes at the next chunk. Within a slow chunk, binary-split to find the pathological line, usually a PO with hundreds of lines or a receipt with huge candidate sets, and handle it specially.

```text
agent timed out on three-way match across 5,000 PO lines and crashed before writing results
```

## Use this when
- The three-way match run over thousands of lines, here 5,000, times out or crashes.
- No results exist after the crash despite the run processing for a long time.
- Manual matching of individual POs works normally.

## Not for this skill when
- Individual PO matches also fail or hang. Then a data or logic problem exists at line level; chunking only contains it, so diagnose the line too.
- The crash is an infrastructure failure like a host restart. Persistence still fixes the cost, but expect normal completion once the host is stable.

## Steps
1. Add per-chunk result writing: each PO group commits its matches and exceptions before the next group starts. Verify: interrupting a test run leaves completed chunks' results intact
2. Instrument chunk durations to find the distribution: most chunks fast, a few extreme. Verify: the slow tail is identified by PO
3. Split slow chunks further and inspect their worst PO for structural causes: line count, receipt count, or candidate explosion. Verify: each slow PO has a named structural cause
4. Process pathological POs with a dedicated path, such as pre-filtered candidates or manual review, outside the main run. Verify: the main run no longer contains a known pathological item
5. Run the full 5,000 lines chunked with a progress report by chunk count and exception count. Verify: the run completes or resumes cleanly, with results for every chunk accounted

## Variant phrasings
### three way match 5000 lines timeout crash no results saved
The volume-crash phrasing.
### chunked PO matching write results per chunk resume
When chunking the match run.

Compatibility: Agent and batch three-way match over ERP purchasing data at thousands of PO lines.

## Why it happens
Batch matching inherits the worst line's cost. One PO with a thousand receipt lines or a vendor whose invoices all share amounts can dominate a run designed for the average line, and end-only writing turns that dominance into total loss. Chunked commits change the economics: progress becomes durable, the slow tail becomes visible as data rather than as a dead job, and pathological items get the individual attention they were always going to need.

## Edge cases / pitfalls
- Chunk by PO keeps a PO's lines together, which the match semantics need; chunking by arbitrary line ranges can split a PO across runs.
- A progress report by chunks doubles as the close status: matched chunks, exception counts, and what remains, without extra tooling.
- Reprocessing a completed chunk after a fix should be an explicit choice, not a side effect of resuming.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_M5qyO0JErQY6UrpxoULLLw