Implement head v2 events for validator clients - #11130
Conversation
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Reviewed by Cursor Bugbot for commit 0369dfd. Configure here.
| Builder::executionOptimistic) | ||
| .withField( | ||
| "payload_status", STRING_TYPE, HeadV2Event::payloadStatus, Builder::payloadStatus) | ||
| .build(); |
There was a problem hiding this comment.
Head_v2 schema mismatch
High Severity
HeadV2Event.TYPE_DEFINITION does not match the wire format Teku emits for head_v2. The beacon node sends a versioned envelope (version + data) with current_epoch_dependent_root and next_epoch_dependent_root, but the client expects a flat payload using the legacy previous_duty_dependent_root / current_duty_dependent_root names. Every head_v2 message fails deserialization and is counted as an invalid event, so the new subscription never drives duty updates.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 0369dfd. Configure here.
There was a problem hiding this comment.
our head event structure may not be consistent on both sides of the wire by the sounds of this
|
|
||
| final List<EventType> eventTypes = new ArrayList<>(); | ||
| eventTypes.add(EventType.head); | ||
| eventTypes.add(EventType.head_v2); |
There was a problem hiding this comment.
Dual head event subscription
Medium Severity
The event stream subscribes to both head and head_v2. Beacon nodes emit both for the same head update during the transition, so a working head_v2 parser would invoke onHeadUpdate and onAttestationCreationDue twice per slot. Other clients prefer head_v2 with a fallback to head rather than listening to both at once.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 0369dfd. Configure here.
There was a problem hiding this comment.
im not sure how hard a fallback would be - if you subscribe and head_v2 isnt present, im not sure we'd know (except never seeing it) - maybe worth digging into...
2 participants
PR Description
Allow validator clients to listen to head_v2 events to address a Cursor bot comment in #11127
Note
Medium Risk
Changes validator head-event handling and timing triggers; subscribing to both head and head_v2 could duplicate duty signals if the beacon node emits both for the same head.
Overview
Validator clients now subscribe to
head_v2on the beacon node events stream alongside the existingheadtopic, and handle incominghead_v2payloads.A new
HeadV2Eventtype deserializes the v2 JSON (includingpayload_statusand the other v2 fields).handleHeadV2Eventdrives the sameValidatorTimingChannelupdates ashead—onHeadUpdateand optional early attestation viaonAttestationCreationDue—using slot, duty roots, and block root only.Subscription URL expectations in
EventSourceBeaconChainEventAdapterTestare updated so both head topics appear in thetopicsquery parameter.Reviewed by Cursor Bugbot for commit 15407c0. Bugbot is set up for automated code reviews on this repo. Configure here.