You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Disable staleness watchdog for frozen Moonbeam chain (#27)
Moonbeam stopped producing blocks at 16,796,699 (0x1004c1b). Because
the chain will never produce a new block, the WSConn staleness
watchdog was closing every connection within 120s and the NodeProxy
was spawning a replacement — both pointing at the same healthy
provider, which never got a newHeads frame to satisfy the freshness
check. The repeated :DOWN messages and the new connections' open_loop
handshakes swamped the Moonbeam NodeProxy mailbox (observed at
>500k pending messages on as1), which in turn made every
eth_getCode from FleetValidation time out at 25s and crash the EdgeV2
ticket handler.
Make the staleness opt-in per chain:
- Chains.Moonbeam.frozen?/0 and final_block_number/0 declare the
chain's permanent head.
- RemoteChain.frozen?/1 and final_block_number/1 default to
false/nil for any chain that doesn't opt in, so Base, Diode, Oasis
and Anvil are unaffected.
- RemoteChain.WSConn.stale_at?/3 and the :ping handler short-circuit
to false for frozen chains. The subscription_id guard is preserved
so a real disconnect still tears the WSConn down.
- RemoteChain.ChainList.block_current?/2 accepts the final block on a
frozen chain regardless of timestamp age, so endpoint re-probes on
the 5-minute TTL don't reject the provider as 'stopped advancing'.
Regression tests cover the new opt-in behaviour, the staleness
short-circuit, and the block_current? branch for frozen chains.
0 commit comments