carlos / platform Public

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

Still outstanding: Deploy reports live while the warm child serves the old binary; ProbeVersion and WaitHealthyVersion exist for exactly this and have no callers.

---

Found redeploying hello (bdf) on the flagship, 2026-08-22.

What happened: carlos deploy -app hello ... -version 9e2d2fc (console mode) shipped, promoted to edge, and printed live https://hello.bdf.oncarlos.com. The registry's route row moved to 9e2d2fc, /opt/carlos/live/hello.bdf.oncarlos.com was re-pointed at the new staged binary — but the already-running instance child (an exec'd process holding the old inode) was never recycled, so every request kept getting the old app. Meanwhile the edge stamps x-carlos-version from the registry row, so the header claimed 9e2d2fc over old-binary responses — the deploy watch verified against a header that no longer described the running process. It served the stale build until a manual pkill let the activator boot the new binary.

Expected: promotion adoption for instance routes should drain-and-recycle a running child (the same SIGTERM path hibernation uses), or the live-watch should verify against something the running child controls (e.g. its own /api/version body) rather than the edge-stamped header.

Notes: a hibernating instance asleep at promote time adopts correctly on next wake — the bug only bites a warm instance. Sibling of platform#112 (watch doesn't cover instance-less static apps).

🤖 Generated with Claude Code