adopt: a converged daemon whose caps.Restart fails stays down until the next hourly pass Issue open
Migrated from github.com/carlosframework/platform issue #292, opened 2026-08-25. GitHub issues are closed for this repo; see AGENTS.md, "Work is tracked on amadan, not GitHub".
Still outstanding: A converged daemon whose caps.Restart fails with an unchanged socket half stays down until the next hourly pass.
---
Found during the console-as-an-app branch (Task 7 review), deliberately not folded into that converge-grade change.
The gap
internal/release/adopt.go's restart-failure block now starts a named unit again after a rolled-back adoption (that branch's fix). But the capability-route arm is different: for a converged daemon route, rerr comes from caps.Restart, and caps.Restore only re-runs the socket sequence when the socket half actually changed (internal/caps/converge.go).
So a converged daemon whose caps.Restart fails with an unchanged socket half is left down until the next hourly pass.
What is and isn't at stake
- No lying stamp.
caps.Restartissystemctl restart, nottry-restart, so it does start a stopped unit and the next pass retries honestly. This is not the second-order failure the console branch fixed. - Real downtime, though: up to an hour on a route nobody is watching.
Why it wasn't fixed there
Folding a second recovery mechanism into a fleet-wide, root-side change would have widened the blast radius of a diff that was already the most delicate in its branch. makeStartRoute correctly returns nil for such a route today — the gap is real but it is a different mechanism.
🤖 Generated with Claude Code