R-379 fix: the rollback must re-discover the DB container
gates / gates (push) Successful in 12s

Found by v0.220.0's own live walk on its first real run. writeSafetyDump
captures its DiscoveredDB before the stop; the DB-only start then re-creates the
container with a new id, so the rollback's docker exec hit a dead container and
sat in waitDBReady for 30s. The app was held for an infrastructure reason while
its data was recoverable.

Re-discover and match by {stack, engine} - what reimportDBDumpsFrom already did.
Fail closed when the container cannot be found.

No unit test caught it because they all inject the import seam and never look at
container identity. The new test asserts the identity handed to the import.
This commit is contained in:
2026-08-22 18:14:31 +02:00
parent 2c724c9283
commit 5b52a5964d
3 changed files with 154 additions and 2 deletions
+22
View File
@@ -1,3 +1,25 @@
## v0.220.1 — the rollback poured the undo into a container that no longer existed (2026-08-22, R-379)
**MinAgent: 0.129.0** (unchanged)
**Found by v0.220.0's own live walk, on its first real run, an hour after it shipped.** The undo FILE
is stable; the container it must be poured into is not. `writeSafetyDump` captures its
`DiscoveredDB` **before** the stop, and by the time the rollback runs the stack has been stopped and
the DB service re-created with a new id.
Measured on `demo-hp`: `docmost-postgres` was captured as `9adbc14f9af6` at 16:05:44, re-created as
`309795897b82` at 16:05:47 by the DB-only start, and the rollback's `docker exec` against the dead id
sat in `waitDBReady` until it timed out 30 s later. **So the app was HELD for an infrastructure reason
while its data was perfectly recoverable** — the hold worked exactly as designed, on a case that
should never have reached it.
The rollback now re-discovers the containers and matches each undo file to a live one by
`{stack, engine}`, which is what `reimportDBDumpsFrom` already did for the replay. A database whose
container cannot be found fails **closed** rather than pouring an undo into something unidentified.
**Why no unit test caught it:** every rollback test injects the import seam and never looks at
container identity. The new one asserts the identity handed to the import, and its red-proof — using
the captured id again — convicts.
## v0.220.0 — when a database restore fails, the customer's own copy goes back (2026-08-22, R-379/R-380/R-381/R-382)
**MinAgent: 0.129.0** (unchanged — no new agent coupling)