What is wrong
Writes that failed are silently ignored, so what the UI shows can differ from what is on disk.
persist_sessions ignores a failed write of sessions.json.tmp, and ignores a failed rename over sessions.json (crates/colonizer/src/sessions.rs:253-262).
append_line, used for the events and logs of every colony, discards a failed write_all (sessions.rs:290-292).
- On startup, a
sessions.json that can't be read or parsed becomes an empty list (crates/colonizer/src/main.rs:335). Every colony then disappears from the UI, although its worktree, branch and microVM may still exist. The next persist overwrites the corrupt file, so it can't be recovered either.
After a failed write, colonies keep running and the UI keeps showing progress, but the event log, the evidence of what happened, can have gaps. Nobody is told.
What done looks like
- A failed persist or append is logged loudly and visible in the UI. The mothership doesn't report success until the write is confirmed.
- A corrupt
sessions.json is moved aside, for example to sessions.json.corrupt-<time>, instead of being overwritten, and the UI says so.
- Tests inject EIO, ENOSPC, permission-denied and rename failures.
Source: external audit of v0.1.3 (d89ce76), finding F08. Confirmed against the code.
Credited to @colonizer-settlers as co-author on this issue.
What is wrong
Writes that failed are silently ignored, so what the UI shows can differ from what is on disk.
persist_sessionsignores a failed write ofsessions.json.tmp, and ignores a failed rename oversessions.json(crates/colonizer/src/sessions.rs:253-262).append_line, used for the events and logs of every colony, discards a failedwrite_all(sessions.rs:290-292).sessions.jsonthat can't be read or parsed becomes an empty list (crates/colonizer/src/main.rs:335). Every colony then disappears from the UI, although its worktree, branch and microVM may still exist. The next persist overwrites the corrupt file, so it can't be recovered either.After a failed write, colonies keep running and the UI keeps showing progress, but the event log, the evidence of what happened, can have gaps. Nobody is told.
What done looks like
sessions.jsonis moved aside, for example tosessions.json.corrupt-<time>, instead of being overwritten, and the UI says so.Source: external audit of v0.1.3 (
d89ce76), finding F08. Confirmed against the code.Credited to @colonizer-settlers as co-author on this issue.