Follow-up to #170. Not a regression: #170's startup resilience is a net improvement. This is a gap in how the mesh consumes it.
Gap
#170 added a DB-probed /ready (503 on outage) and gates Fly routing/deploys on it. But peer liveness still pings /health, which the full server pins at a constant 200 with no DB check (server.rs:484). ping_peer_health (main.rs:962) and api/peers.rs:434 both target /health and treat any 2xx as alive.
Evidence (executed)
Built the full router against a state whose DB is unavailable and drove both endpoints:
/health -> 200 OK (ignores DB state)/ready -> 503 Service Unavailable (reflects DB state)
Consequence
A DB outage that happens after startup leaves /health at 200 forever, so peers keep counting the node alive and routing sync/gossip to it while every DB-touching endpoint 503s. #170's drain-on-outage goal holds for the Fly edge (which reads /ready) but not the P2P mesh. The commit message's claim that peers "stop counting a DB-less node as alive" is only true during the startup window, where the degraded server 503s /health.
Direction
Point the peer liveness ping at /ready (readiness), or fold a DB-state check into the peer-routing decision. Keep /health as pure liveness so Fly's kill/restart semantics are unaffected.
Follow-up to #170. Not a regression: #170's startup resilience is a net improvement. This is a gap in how the mesh consumes it.
Gap
#170 added a DB-probed
/ready(503 on outage) and gates Fly routing/deploys on it. But peer liveness still pings/health, which the full server pins at a constant 200 with no DB check (server.rs:484).ping_peer_health(main.rs:962) andapi/peers.rs:434both target/healthand treat any 2xx as alive.Evidence (executed)
Built the full router against a state whose DB is unavailable and drove both endpoints:
/health-> 200 OK (ignores DB state)/ready-> 503 Service Unavailable (reflects DB state)Consequence
A DB outage that happens after startup leaves
/healthat 200 forever, so peers keep counting the node alive and routing sync/gossip to it while every DB-touching endpoint 503s. #170's drain-on-outage goal holds for the Fly edge (which reads/ready) but not the P2P mesh. The commit message's claim that peers "stop counting a DB-less node as alive" is only true during the startup window, where the degraded server 503s/health.Direction
Point the peer liveness ping at
/ready(readiness), or fold a DB-state check into the peer-routing decision. Keep/healthas pure liveness so Fly's kill/restart semantics are unaffected.