The activity log (#145) records per-node events by diffing each node against its own previous state (diff_tips compares a node's getchaintips result to that node's earlier one). That's the right foundation, but the signal fork-observer uniquely exists to catch only becomes visible when you correlate events across nodes at the same height. This issue is about deriving that cross-node signal and alerting on it.
Two situations are worth a dedicated, network-level event:
- One node reports
invalid-block-observed for a block that another node has as its active tip. That is the scariest thing on the network: a possible consensus bug, a soft-fork enforcement split, or an attack. Right now nobody is told about it even though both single-node events are already in the log.
- Nodes are stuck on different active tips at the same height for a sustained window — a real chain split, which is distinct from the existing
node-lagging signal (that just means "behind on the same chain"). Transient disagreement during propagation should be filtered out with a time/height threshold so this only fires on genuine divergence.
The activity log enables this directly. The per-node events and the shared header tree are already there; divergence detection is a matter of joining them and emitting a new event — say consensus-divergence / network-split-detected. Usefully, the activity table's node column is already nullable, so a network-scoped (not node-scoped) event fits the existing schema with no migration. Once emitted, it flows through the same writer, cache, API, and pages as every other event.
This pairs naturally with the webhook/RSS alerting issue: divergence is precisely the event an infra team running multiple node versions would want pushed to them immediately, so this is the flagship thing that alerting would fire on.
The activity log (#145) records per-node events by diffing each node against its own previous state (
diff_tipscompares a node'sgetchaintipsresult to that node's earlier one). That's the right foundation, but the signal fork-observer uniquely exists to catch only becomes visible when you correlate events across nodes at the same height. This issue is about deriving that cross-node signal and alerting on it.Two situations are worth a dedicated, network-level event:
invalid-block-observedfor a block that another node has as its active tip. That is the scariest thing on the network: a possible consensus bug, a soft-fork enforcement split, or an attack. Right now nobody is told about it even though both single-node events are already in the log.node-laggingsignal (that just means "behind on the same chain"). Transient disagreement during propagation should be filtered out with a time/height threshold so this only fires on genuine divergence.The activity log enables this directly. The per-node events and the shared header tree are already there; divergence detection is a matter of joining them and emitting a new event — say
consensus-divergence/network-split-detected. Usefully, the activity table'snodecolumn is already nullable, so a network-scoped (not node-scoped) event fits the existing schema with no migration. Once emitted, it flows through the same writer, cache, API, and pages as every other event.This pairs naturally with the webhook/RSS alerting issue: divergence is precisely the event an infra team running multiple node versions would want pushed to them immediately, so this is the flagship thing that alerting would fire on.