fix: emit head event whenever fork choice head changes - #9697
Merged
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
馃挕 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 11e1b3a003
鈩癸笍 About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 馃憤.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Comment on lines
+1191
to
+1193
| const head = this.forkChoice.updateAndGetHead({mode: UpdateHeadOpt.GetCanonicalHead}).head; | ||
|
|
||
| if (head.blockRoot !== prevHead.blockRoot) { |
There was a problem hiding this comment.
When the first canonical recompute after attestation weight shifts happens through block production, this new emission path is bypassed: BeaconChain.getProposerHead() calls forkChoice.updateAndGetHead({mode: GetProposerHead}), and ForkChoice.updateAndGetHead() runs updateHead() for that mode before returning. In that scenario the cached canonical head changes, but no head SSE event is emitted, so validators watching head events can still miss the duty-dependent-root update until some later recomputeForkChoiceHead() call.
Useful? React with 馃憤聽/ 馃憥.
Member
Author
There was a problem hiding this comment.
this is intentional, we explicitly don't want to emit a head event on the proposer path when we are proposing a block ourselves
that head change is superseded once we import our own block, which emits the head event with the correct dependent roots, so head event consumers aren't affected in practice
Contributor
Performance Report鉁旓笍 no performance regression detected Full benchmark results
|
wemeetagain
previously approved these changes
Jul 23, 2026
twoeths
reviewed
Jul 24, 2026
| const prevHead = this.forkChoice.getHead(); | ||
| const head = this.forkChoice.updateAndGetHead({mode: UpdateHeadOpt.GetCanonicalHead}).head; | ||
|
|
||
| if (head.blockRoot !== prevHead.blockRoot) { |
Member
There was a problem hiding this comment.
getProposerHead() also changes the head, it's worth to extract this to a separate method to reuse?
Member
There was a problem hiding this comment.
nvm, getProposerHead() is different, could be a proposer boost reorg there
maybe just drop a comment on why we don't need to emit a head event over there
Member
Author
There was a problem hiding this comment.
as noted in the PR description I intentionally don't wanna consider the proposer path, I think it is fine to rely on the block import path in that case, we can add the comment as you suggested
twoeths
approved these changes
Jul 24, 2026
Member
|
馃帀 This PR is included in v1.46.0 馃帀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
headevent is only emitted on block import, but the node's head can change without a new block (e.g. attestation weight shifts duringprepareNextSlot).Emit
headfromrecomputeForkChoiceHeadon any head root change, so it fires on block import and standalone recomputes (e.g.prepareNextSlot) alike, instead of only fromimportBlock.Note we intentionally don't emit on the proposer path (
getProposerHead) when proposing a block ourselves, as that head change is superseded once we import our own block.