connectionStateChanged is only emitted on a transition — node_health_monitor compares against the last notified state and stays silent otherwise — and there is no method to read the status. So any consumer that starts listening after the node reached steady state has no way to learn the current state, possibly for a very long time.
This is not hypothetical: on a shared node (one delivery_module per Logos Core instance) the module that did not create the node is always a late subscriber. In logos-delivery-demo running next to logos-chat-module, the connection badge therefore stays blank until the node's next transition — see logos-co/logos-delivery-demo#21.
Neither of today's workarounds is acceptable for a consumer: parsing getNodeInfo("Metrics") for a peer gauge is fragile and can't distinguish Connected from PartiallyConnected (that needs the health monitor's per-protocol view), and re-deriving the status from scratch duplicates the monitor.
Either fix works:
- a queryable snapshot of the current status (a
getStatus() method, or a ConnectionStatus node-info id — the latter likely needs a NodeInfoId addition in logos-delivery's waku_state_info.nim), or
- re-emit the current status to each new listener on subscribe.
Same underlying gap as #36, whose Option B (getStatus() returning connectionStatus + peerCount) would resolve this — fold this in there if that's the preferred shape; filing separately because #36 is framed around peer count and is waiting on evidence capture.
connectionStateChangedis only emitted on a transition —node_health_monitorcompares against the last notified state and stays silent otherwise — and there is no method to read the status. So any consumer that starts listening after the node reached steady state has no way to learn the current state, possibly for a very long time.This is not hypothetical: on a shared node (one
delivery_moduleper Logos Core instance) the module that did not create the node is always a late subscriber. Inlogos-delivery-demorunning next tologos-chat-module, the connection badge therefore stays blank until the node's next transition — see logos-co/logos-delivery-demo#21.Neither of today's workarounds is acceptable for a consumer: parsing
getNodeInfo("Metrics")for a peer gauge is fragile and can't distinguishConnectedfromPartiallyConnected(that needs the health monitor's per-protocol view), and re-deriving the status from scratch duplicates the monitor.Either fix works:
getStatus()method, or aConnectionStatusnode-info id — the latter likely needs aNodeInfoIdaddition in logos-delivery'swaku_state_info.nim), orSame underlying gap as #36, whose Option B (
getStatus()returningconnectionStatus+peerCount) would resolve this — fold this in there if that's the preferred shape; filing separately because #36 is framed around peer count and is waiting on evidence capture.