Recover an Ethereum event consumer after a WebSocket disconnect
A subscription ID belongs to the connection that created it. A consumer that needs every matching event must recover the interval between its last durable checkpoint and the new connection.
Subscribe before starting recovery
On the new socket, subscribe to notices of new heads and wait for the subscription ID. For a consumer of finalized events, use these notices as a signal to poll. The following request goes through the WebSocket connection.
{"jsonrpc":"2.0","id":1,"method":"eth_subscribe","params":["newHeads"]}
Immediately fetch eth_getBlockByNumber with ["finalized",false] over RPC. Suppose the database records block 850 as the last complete finalized block and the endpoint returns block 875. Fetch the application’s event filter with eth_getLogs over the inclusive interval 851–875. There is no dependency on reconstructing all 25 head notifications.
Save progress after processing
Commit each completed batch of events together with its ending height and block hash. On restart, check that the stored hash still matches the backend at that height. If it differs, pause recovery and check the chain ID and endpoint before appending further events. On every wake-up, scan again from the next unprocessed height through the current finalized head.
Treat silence as a reason to poll
A periodic poll recovers progress if a connection becomes half-open. The interval can follow the application’s latency budget. This design deliberately waits for finality. Applications showing provisional logs also need to reverse effects when a reorganization removes a previously delivered log. geth.ethereum.org Geth subscription lifetime and reorganization behavior