Cleanup sounds straightforward after a failed save. Without knowing which file this attempt created, however, cleanup can affect another task. I examined the actual journal failure and repair, then reproduced the ownership boundary in a small synthetic writer.
Failure can occur after the bytes are written
The original writer stages a file, rechecks context and then renames it to the destination. Context may be canceled after writing, and rename can fail. Avoiding an immediate overwrite protects the old record, but leaves responsibility for a failed stage. Save completion and cleanup are separate questions.
The development record covers post-write context failure, an actual rename failure and invalid-key ordering in pre-fix code. That implementation is a Node journal. The shared Python example instead accepts a small synthetic record, with no real browser receipt, account or tab information.
Ownership begins only after exclusive creation
The new save opens its stage exclusively. If the name already exists, creation fails without claiming that file. Created becomes true only after a successful open, and failure cleanup targets that one owned file. There is no wildcard sweep of temporary extensions.
Tests force a name collision and verify unchanged existing bytes, also retaining an unrelated stage. Similar names and equal extensions are not ownership evidence. The small contract records what was actually created before deciding what may be removed.
Validate before staging and recheck context afterward
Key and exact record fields are validated before creation. Path-like keys and unknown fields fail. The experiment uses an explicitly supplied existing trusted directory. After writing, flushing, syncing and closing, it calls the context check again before replacement.
If context changed, the prior destination stays intact and only this stage is removed. The check remains a caller-provided function, not actual identity authentication. Hostile ancestor-directory replacement and server access enforcement are outside the example; the writer states its trusted-directory assumptions explicitly.
Use an actual replacement failure
A test creates a directory at the destination name so real file replacement fails. Another peer record is saved alongside it. After error, the destination directory and peer bytes must remain. An exception alone is not proof of preservation; tests inspect the files that remain.
Twelve tests use actual local files and pass in source and a fresh ZIP extraction. These are current synthetic executions, separate from the original report’s regression totals. No customer directory or operating application is used as a failure-test target.
Preserve the cleanup error alongside the original
Deleting an owned stage can itself fail after a save error. The example retains both exceptions in an ExceptionGroup so cleanup does not hide cancellation or replacement failure. A stage may remain in that case; callers receive evidence rather than a false clean-state promise.
There is no guarantee of cleanup after process kill or power loss, no directory-sync durability claim across filesystems and no concurrent-writer conflict protocol. Syncing one file must not become a promise that every failure preserves the latest record. Operational recovery policy remains separate.
Share a small file contract with its boundaries
The existing SQLite module concerns relationships within a database transaction. This one concerns replacement boundaries and ownership of a staged file. Neither implementation inherits the other’s guarantee simply because both are called saving. The new module publishes complete code, actual records, tests and ZIP.
Its webpage selector reads stored results without creating or removing visitor files. I prefer an inspectable account of what survives each failure and which file cleanup owns over a broad claim that save errors are solved. Adoption still needs trusted-root and concurrent-writer policy.