feat(sentry): fetch Gloas-aware v2 debug fork choice

[Savid]

Why

Since Gloas activated on Sepolia, the sentry's fork choice events (which feed forky through xatu-internal-kafka-vector-forky) lose the payload information:

• The sentry fetches GET /eth/v1/debug/fork_choice. On Gloas, Teku and Lodestar return three v1 nodes per block (pending/empty/full) and Nimbus two, with no payload_status to tell them apart. Production forky on Sepolia currently receives Teku frames with 266 nodes for 89 blocks.
• ForkChoiceNodeV2.payload_status is read from v1 extra_data["payload_status"], which no client sets, so it is never populated.

What

• Sentry fetches GET /eth/v2/debug/fork_choice (ethereum/beacon-APIs#615, merged 2026-10-07), one node per (block_root, payload_status), and falls back to v1 when v2 fails. Nodes that cannot serve v2 — no endpoint (Lighthouse 400, Nimbus 404) or a response that doesn't follow the spec, which go-eth2-client rejects with ErrInvalidResponse (Teku, Prysm and Lodestar today) — use v1 for an hour before v2 is retried; any other v2 failure (timeout, 5xx) falls back for that fetch only, and a cancelled fetch returns without falling back. The fallback is fetchForkChoiceWithFallback, unit-tested for each case. Uses the new ForkChoiceV2Provider from feat: add GET /eth/v2/debug/fork_choice and keep fork choice store extra data go-eth2-client#60 via the beacon node's Service(), so no ethpandaops/beacon change is needed.
• Proto (additive, so no new event names, Kafka topics or Vector routes):
  • ForkChoiceNodeV2: parent_payload_status (same enum as payload_status: EMPTY=0, FULL=1, PENDING=2, matching the spec's PAYLOAD_STATUS_*), payload_attester_count, payload_availability_yes_count, payload_data_availability_yes_count, and the node's justified_checkpoint / finalized_checkpoint (whose epochs also fill justified_epoch / finalized_epoch, as for v1 nodes).
  • ForkChoiceV2.extra_data: the fork choice store's values (unrealized justified/finalized checkpoints, proposer boost root, …), kept from both endpoints.
• Conversion: NewForkChoiceV2FromGoEth2ClientV2. AsGoEth2ClientV1ForkChoice round-trips the new fields (including the node checkpoints) into node extra_data and the store extra_data onto the v1 type, so existing consumers (forky 1.0.2) still see them. Also fixes a panic in that conversion for nodes without extra data (encoded as JSON null).

Verified

• Unit tests for the v2 conversion (spec-shaped nodes, null parent payload status, checkpoints), the v1 round trip and the fallback decision; go test and golangci-lint (CI setup) pass.
• Live, five branch sentries on Sepolia with fork choice every 20s for 150s: each tried v2 once and fell back to v1 (Lighthouse/Nimbus at debug; Teku parent payload status missing, Prysm/Lodestar fork choice data missing as one warning each), and every node kept producing BEACON_API_ETH_V1_DEBUG_FORK_CHOICE_V2 events from v1.

Until clients implement the merged spec, events come from v1, so the payload status forky needs is still missing, as it is today. It arrives automatically, within the retry interval, once a client's v2 response follows the spec.

Notes for rollout

• Deploy forky first. Production forky (1.0.2) decodes events with strict protojson.Unmarshal, so the new fields (store extra_data, which Prysm and Nimbus send even on v1, and the node fields) would make it drop whole batches. forky release/glamsterdam-sepolia decodes with DiscardUnknown and understands the new fields; roll it out before the server/sentries.

• Event size: v2 has a node per payload status. Teku's Sepolia event is ~425KB as protojson (under Kafka's default 1MB max.message.bytes), but fork choice trees grow during non-finality, so it's worth checking broker/topic and Vector/ingress body limits for the fork choice topics.

• payload_status from the v1 extra_data heuristic is kept for any client that starts reporting it there.

• go-eth2-client#60 decodes v2 strictly to the spec; its description has a table of where each client's current response falls short.

• go-eth2-client is v0.1.10, which includes feat: add GET /eth/v2/debug/fork_choice and keep fork choice store extra data go-eth2-client#60.

🤖 Generated with Claude Code

[redpandabot]

The sentry now prefers GET /eth/v2/debug/fork_choice with an hourly-retried v1 fallback, and ForkChoiceV2 (proto + conversions) carries the Gloas parent_payload_status/PTC counts plus the store extra_data and the JSON-null panic fix. I traced the fetch/fallback control flow, every snapshot consumer, the v1↔v2 round trip, the enum mapping against consensus-specs and the pinned go-eth2-client constants, and the generated vtproto; the change is internally consistent and additive, and the dependency bump is clean on OSV.

---

_{Reviewed 11 changed file(s) @ ede1de64 — no blocking issues found.
"Debugging is twice as hard as writing the code in the first place." — Brian Kernighan}