docs: record how a failed object-store converge is recovered

sean commented

2026-09-09 12:23:35 +00:00

Owner

Two operational facts learned by running the first converges: where the reason is (binjovictl targets / deploy, not an attempt log), and that there is no retry -- retry-deploy is refused for a production target, so recovery is to fix the cause and release again, which is safe because the converge is idempotent. https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76

sean added 1 commit

2026-09-09 12:23:35 +00:00

docs: record how a failed object-store converge is recovered

binjovi/ci Binjovi completed the frozen plan

Details

48a2066258

Two operational facts learned by running the first converges, neither of them
obvious from the file or from Binjovi.

Where the reason is. `binjovictl targets binjovi-plans` shows the target and
`binjovictl deploy <id>` shows why it failed. That matters because a converge
failure is not a build failure: there is no attempt log to read.

There is no retry. `binjovictl retry-deploy` is refused for a production
target, so the recovery for a failed converge is to fix the cause and release
this repository again. That is safe because every step of the converge accepts
the state already in place, which is worth saying plainly -- an operator
looking at a half-converged tenant should not be wondering whether re-running
will double anything.

And it will be half-converged, on purpose. An identity whose scoping cannot be
proved fails the converge where it stands rather than unwinding into a state
nothing declares.

Claude-Session: https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76

binjovi-bot merged commit 48a2066258 into trunk

2026-09-09 12:23:55 +00:00

Rows
Columns

docs: record how a failed object-store converge is recovered #147