Topic‑filtered subscription versus broad getPastLogs with client‑side filtering for Web3.js alert noise

Topic‑filtered subscription versus broad getPastLogs for Web3.js alert noise

When monitoring a contract that emits frequent events, the choice between a topic‑filtered WebSocket subscription and a broad getPastLogs call with client‑side filtering determines both alert noise and reliability. Under high event rates, a topic‑filtered subscription typically produces fewer noisy alerts, because the node filters by indexed parameters before sending data over the wire. However, this approach cannot evaluate non‑indexed fields, and it depends on a stable WebSocket connection.

Likely explanation versus confirmed facts

• Topic‑filtered subscription: The node only delivers logs whose topics match the filter. This reduces network traffic and client‑side processing, which lowers UI noise when the needed criteria are covered by indexed topics.
• Broad getPastLogs + client filtering: The node returns all logs for a block range, and the client applies every filter. This guarantees that no event is missed after a disconnect, but it increases RPC load, latency, and the volume of alerts the UI must evaluate.

Steps for this case

1. Persist the block number of the last processed event.
2. On WebSocket reconnection, subscribe with the same topic filter and use the persisted block number to request any missed range via getPastLogs.
3. Deduplicate alerts by comparing the block range already handled against the recovery call’s results.
4. If the needed filter fields are not indexed, plan to use broad getPastLogs polling or accept that those fields will arrive in every topic‑matched log.

const sub = await provider.getSubscription('logs', { address: contractAddress, topics: [eventSignature] })

Version‑specific considerations

Web3.js v1.x subscriptions emit data and error events; reconnection and resumption must be handled manually, including re‑subscribing and issuing a targeted getPastLogs for the gap. Web3.js v2.x’s Subscription class adds automatic reconnection and resumable‑stream options when the underlying provider supports it, reducing the amount of custom reconnect logic required.

Diagnostic detail required: Are the parameters you need to filter by marked indexed in the Solidity event definition? If they are not, topic filtering is impossible, and you must rely on client‑side getPastLogs polling.