The first attempt had already changed the file
The expense fixture began with 483 raw rows and 480 clean documents. The script appended SEO-RETRY-ONE, a synthetic October document for $1, and saved the workbook. It wrote a checkpoint marker and deliberately raised an error before refreshing the Actuals query.
At that point the saved raw table contained 484 rows, while the cleaned query still contained 480 documents. Both observations were valid descriptions of different stages. Starting over from the instruction “append the document” would ignore the state already committed to the file.
This experiment creates the interruption at a known boundary. It does not reproduce every failure an agent may encounter, and it does not establish exactly-once processing across simultaneous clients. Its narrower question is whether an inspected retry can recognize its own saved input.
A matching ID is only the first check
On recovery, the script counted the exact document identifier in the raw table. More than one match would stop the test. Zero matches would permit the initial append. One match required comparison of all six expected fields: identifier, posting date, department code, category, amount and description.
That payload comparison matters. An existing identifier with a different amount is a conflict to investigate, not permission to continue. In this fixture the fields matched, so appended was false and the raw count stayed at 484.
Only then did the script refresh the named query and recalculate. The clean count rose to 481, the report became $686,501, and the cleaned identifier appeared once. The recovered file reconciled the intended change without another raw append.
| Measure | Interrupted attempt | Recovery |
|---|---|---|
| Raw rows | 484 | 484 |
| Clean documents | 480 | 481 |
| New append during recovery | — | False |
| Report total after recovery | Not accepted | $686,501 |
| Clean witness count | Not checked | 1 |
Keep a checkpoint useful for diagnosis
The marker in this test records that the source-save stage was reached. It is not an atomic transaction spanning the workbook and a separate file. The recovery therefore inspects the workbook itself; it does not use the marker as proof that the expected payload is present.
For a longer close, record the input file identities, task-specific document IDs, accepted source totals and the last completed stage. After an uncertain command, inspect files and the Office window before resubmitting it. A timeout describes what the controller observed; it need not describe every side effect in the application.
Keep append, refresh, validation and delivery as explicit stages. A recovered source does not authorize sending the output until the downstream query, formulas, pivots and presentation checks pass. Our experiment accepts the source/query/report checks only; it does not claim a fully validated management deck.
Run the interruption and recovery deliberately
Download the recovered workbook, result record and script. Put the synthetic expense workbook in a new directory as expense-original.xlsx. The first invocation deliberately fails after saving its own copy; inspect that copy before the second invocation.
Never use this failure-injection script on an existing customer workbook. It writes a known synthetic row and uses a local marker to select the test stage. Adapt the reconciliation contract to your data before using the pattern in a real process.
Use the Panes command docs for execution and the duplicate-document guard for conflicting or blank identifiers. The guard and the retry solve related problems at different points: input acceptance and recovery after a committed edit.