Back to notes
The Tesseract MemoryTechnical note

Recovering a media import before its receipt exists

An interrupted import can leave valid assets behind. Rebuilding indexes from their manifests lets a retry keep those identities instead of creating duplicates.

Topics

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.

Direct callResponse / return
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)
  1. 01 · Scanned import plan02 · Idempotency checkrequest hash · Direct call
  2. 02 · Idempotency check03 · Saved import resultmatching receipt · Response / return
  3. 02 · Idempotency check04 · Per-product lockno saved receipt · Direct call
  4. 04 · Per-product lock06 · Rebuild derived indexesrecheck then recover · Direct call
  5. 05 · Existing asset manifests06 · Rebuild derived indexesexisting identities · Direct call
  6. 06 · Rebuild derived indexes07 · Verified staged copynew accepted content · Direct call
  7. 06 · Rebuild derived indexes08 · Manifest and index writesreuse and repair · Direct call
  8. 07 · Verified staged copy08 · Manifest and index writesverified bytes · Direct call
  9. 08 · Manifest and index writes09 · Final idempotency receiptrecord completed result · Direct call
  10. 09 · Final idempotency receipt02 · Idempotency checkfuture retry · Response / return