Found during review of #345 (closed), and the original motivation for that PR. The gap is real; the fix attempted there was not.
What is uncovered
docs/PUBLICATION_READINESS.md records six recovery scenarios per selection. None of them covers the window in which the workbook and ZIP are built and exported, even though that window has durable ledger state:
zipPhase: "export-pending" persisted immediately before exportFullFiscalYearZip
zipPhase: "export-retry-pending" set on a handled non-downloaded return
A restart during that window must rebuild and export the completed plan without repeating portal targets. Nothing asks whether it does.
Two things to get right, both learned the hard way in #345
1. A boundary refusal is not evidence. If this becomes a matrix column, fail-closed-as-expected must not be completion-eligible for it. Rebuilding and exporting is the property being claimed; a refusal does not demonstrate it. Every other scenario column accepts a boundary refusal, so this needs its own rule family rather than reusing the generic validator.
2. export-retry-pending is not where a killed worker lands. It is set only on a handled return path (filed-returns-all-supported-full-fiscal-year.ts:630). If Chrome terminates the worker while completeRun is awaiting exportFullFiscalYearZip, execution never reaches the post-await transition and the ledger stays at its last persisted phase -- typically export-pending, download-intent-persisted, or download-observing. Any wording that says an interrupted export "moves to export-retry-pending" is wrong for the termination case, which is the case worth testing. #345 stated exactly that and had to be corrected.
Also unresolved: which restart
A single export observation cannot say whether the restart tested was a service-worker restart or a full browser restart. They differ here: a browser restart additionally tears down the offscreen document and any in-flight browser download activity, while a worker restart can be satisfied earlier during target acquisition. Tracked separately in #348.
Related
#346 covers the parallel all-supported export orchestration, which this path does not reach. Both concern the same window and should probably be decided together.
Found during review of #345 (closed), and the original motivation for that PR. The gap is real; the fix attempted there was not.
What is uncovered
docs/PUBLICATION_READINESS.mdrecords six recovery scenarios per selection. None of them covers the window in which the workbook and ZIP are built and exported, even though that window has durable ledger state:A restart during that window must rebuild and export the completed plan without repeating portal targets. Nothing asks whether it does.
Two things to get right, both learned the hard way in #345
1. A boundary refusal is not evidence. If this becomes a matrix column,
fail-closed-as-expectedmust not be completion-eligible for it. Rebuilding and exporting is the property being claimed; a refusal does not demonstrate it. Every other scenario column accepts a boundary refusal, so this needs its own rule family rather than reusing the generic validator.2.
export-retry-pendingis not where a killed worker lands. It is set only on a handled return path (filed-returns-all-supported-full-fiscal-year.ts:630). If Chrome terminates the worker whilecompleteRunis awaitingexportFullFiscalYearZip, execution never reaches the post-await transition and the ledger stays at its last persisted phase -- typicallyexport-pending,download-intent-persisted, ordownload-observing. Any wording that says an interrupted export "moves toexport-retry-pending" is wrong for the termination case, which is the case worth testing. #345 stated exactly that and had to be corrected.Also unresolved: which restart
A single export observation cannot say whether the restart tested was a service-worker restart or a full browser restart. They differ here: a browser restart additionally tears down the offscreen document and any in-flight browser download activity, while a worker restart can be satisfied earlier during target acquisition. Tracked separately in #348.
Related
#346 covers the parallel all-supported export orchestration, which this path does not reach. Both concern the same window and should probably be decided together.