The last write isn't the only durable one
The intake service saves its receipt after copying files, writing manifests, updating indexes and recording status and events. An interruption can therefore leave a real asset and manifest on disk without a completed request to replay. An absent receipt isn't proof that the import did nothing.
Each replacement is atomic on its own. The recovery problem sits between those replacements: the next attempt needs to recognise what survived and finish the derived records without inventing a second identity for the same content.
Replay the request or rebuild from the assets
For a completed import, the idempotency key points to a saved result and request hash. That hash includes the product, source classification, rights reference, scanned paths and content hashes. An exact retry gets the original result; changed inputs under the same key are rejected. The service repeats the lookup inside the product lock because another caller may have completed the request while it waited.
When there's no receipt, existing manifests rebuild the indexes by asset ID, content hash and original filename. Duplicate detection then uses those repaired indexes, allowing matching content to keep its identity. The recovery test removes a receipt and clears the indexes, then expects a retry to restore them without creating another manifest.
Verify the bytes that still need copying
New content is copied into an exclusively created temporary file, flushed, synced and hashed against the value from the scan. Only a matching copy is moved into place. Different content already at the destination raises a conflict rather than being replaced.
The tests also cover filename collisions, changed retry inputs and rights references from another product. Those references are rejected before copying, but a successful copy still doesn't approve the asset's use. The tests were inspected, not rerun, and this review imported no media. The recovery path completes work from saved records; it doesn't promise a whole-import rollback.
Completed-request replay and partial-import recovery
A receipt can replay a completed import; manifests can recover an import whose receipt was never written.
Request and planning
Locked intake service
Local durable records
Scroll or drag the background to move. Use the zoom buttons to resize.Arrow keys move between components. Enter selects.
Choose a component to explore
Select a numbered component on the map or use the component menu. Its details and connections will appear here.
No component selected.
All connections (10)
- 01 · Scanned import plan → 02 · Idempotency checkrequest hash · Direct call
- 02 · Idempotency check → 03 · Saved import resultmatching receipt · Response / return
- 02 · Idempotency check → 04 · Per-product lockno saved receipt · Direct call
- 04 · Per-product lock → 06 · Rebuild derived indexesrecheck then recover · Direct call
- 05 · Existing asset manifests → 06 · Rebuild derived indexesexisting identities · Direct call
- 06 · Rebuild derived indexes → 07 · Verified staged copynew accepted content · Direct call
- 06 · Rebuild derived indexes → 08 · Manifest and index writesreuse and repair · Direct call
- 07 · Verified staged copy → 08 · Manifest and index writesverified bytes · Direct call
- 08 · Manifest and index writes → 09 · Final idempotency receiptrecord completed result · Direct call
- 09 · Final idempotency receipt → 02 · Idempotency checkfuture retry · Response / return