carlos / platform Public

Migrated from github.com/carlosframework/platform issue #109, opened 2026-08-08. GitHub issues are closed for this repo; see AGENTS.md, "Work is tracked on amadan, not GitHub".

Still outstanding: A cycled route can be left unarmed, so nothing wakes it until the hourly adopt pass.

---

What happened

On the flagship box (i-092c0c1eea75723cb), the amadan.net exec route went 502 for ~29 minutes after a release cycle, because the activator hibernated it during the cycle and then never attempted a wake — every request hit the router's dead-socket path until the next hourly adopt pass re-reconciled and spawned it.

Timeline (2026-08-08 UTC)

• 13:33 — operator-triggered systemctl start carlos-adopt.service after promoting amadan-hub 89196e9 to beta+edge.
• 13:35:20 — activator: amadan.net serving 5b75af0 but live symlink is now 89196e9 — cycling onto the new build → activator: next-due probe amadan.net: read env file: open /data/amadan.net.env: no such file or directory — recording none (it sleeps until a request) → activator: amadan.net hibernated.
• 13:36 → 14:04 — every request: http: proxy error: dial unix /run/carlos/amadan.net.sock: connect: no such file or directory (502 after ~13s). No wake/spawn line was ever logged. No amadan-hub process existed.
• 13:44:26 — carlos-edge restarted (cause unknown, not operator). Wake still broken after restart.
• 13:50 — operator restarted carlos-edge deliberately. Still broken.
• 13:5x — rolled the ladder back to 5b75af0 + another adopt pass: still broken — so it was not the new release; the same binary that had served all morning also wouldn't wake.
• 14:04:14 — (hourly adopt loop, armed 13:51 + jitter) — INFO rastrillo: serving addr=/run/carlos/amadan.net.sock: route recovered by itself on the rolled-back release.

What makes it look like an arming bug

• seapointish.bag.oncarlos.com went through the same cycle at 13:37:20 (serving 32927a8 but live symlink is now 51c5192) and woke normally on request afterwards (303 in 0.4s), on the same edge process.
• Two earlier amadan cycles the same day (12:20, 12:53, same operator flow) recovered within minutes.
• Env config /data/amadan.net.config.env was intact throughout (all AMADAN_ vars); both releases staged under /opt/carlos/versions/.
• The 13s 502 latency reads like the router proxying to the socket with retries rather than consulting the activator — as if the route's hibernated/armed state was lost in the cycle path (and survived two edge restarts, so wherever that state lives, it wasn't repaired by a fresh boot; only the hourly adopt reconciliation fixed it).

Expected

A cycled route should either be respawned by the cycle itself or reliably wake on the next request — never sleep until the hourly adopt pass while requests 502.

Notes

• The next-due probe … read env file … recording none line fires for routes without /data/<route>.env (amadan uses /data/<route>.config.env) — informational, but it is the last activator line before the route went dark, so possibly related to how the post-cycle state is recorded.
• Filed from the amadan deploy session; happy to provide fuller journal extracts.

🤖 Generated with Claude Code

https://claude.ai/code/session_0182YKveLJNi2WB8h5vNuK8v