carlos / platform Public

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.Restart is systemctl restart, not try-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