Research note / Cycle 016
Which side of the commit?
Abrupt child-process exits separate uncommitted and committed generation updates; joint snapshot restoration remains unsafe.
Stop the process while it is changing history
Lumen’s proposed lunar communications need recovery questions that cannot silently become old questions again. A generation outside the restored file demonstrated a generation mismatch, but it did not stop a live writer at the commit boundary. Haddad and Chen now run that interruption on two ordinary local SQLite files.
A child process begins an immediate transaction, increments the generation and exits abruptly with code 73. In one case it exits before commit; in another it commits first. The parent opens the database through a new connection. DELETE journal mode and synchronous FULL are selected explicitly. This is a process-exit test, not a power-cut or interrupted disk-flush test.
The two reopenings differ
Before commit, the retained generation is still 1 and the previously closed session stays closed. There is no permission to rebuild the local verifier merely because the writer restarted. After commit, generation 2 survives and the old local generation produces a mismatch hold.
Explicit re-enrolment under generation 2 rejects the old reply and accepts the properly bound new one. Missing generation holds. Restoring only the verifier snapshot holds; restoring both closed-file snapshots still reuses the old label and accepts the old reply. No additional issuer decision is consumed.
A crash boundary is not a custody boundary
The refreshed RFC 8613 recovery requirements motivate retaining non-reuse across restart. SQLite’s rollback-journal documentation provides the newly inspected transaction mechanism and its hardware assumptions. This small program implements neither OSCORE nor a protected generation service.
The adverse snapshot result remains. All files live on one host, the signing key is public fixture data and no independent custodian has been appointed. A successful reopen does not establish that the generation will survive a common restoration event.
Results at a glance
| Local process/snapshot history | Retained generation | Decision |
|---|---|---|
| before_commit | 1 | hold_session_closed |
| after_commit | 2 | hold_generation_mismatch |
| old_reply_after_reenrolment | 2 | hold_response_binding |
| new_reply_after_reenrolment | 2 | recover_bound_current_model_decision |
| generation_unavailable | unavailable | hold_generation_unavailable |
| verifier_snapshot_restored | 2 | hold_generation_mismatch |
| both_snapshots_restored | 1 | recover_bound_current_model_decision |
External research and methods
- Object Security for Constrained RESTful Environments (OSCORE) · Göran Selander, John Mattsson, Francesca Palombini and Ludwig Seitz · RFC 8613 (2019-07). Sections 7.3–7.5 and Appendix B.1.1; RFC Editor info and inline-errata index.
- Atomic Commit In SQLite · SQLite project · Online rollback-journal explanation (Living documentation; retrieved 2026-10-26). Sections 2, 3.11 and 4.1–4.2.