fix: orphan-status badge in list views + Docker buildability#693
Merged
Conversation
barnabasbusa
changed the title
3 tasks
getPayloadStatus unconditionally returned PayloadStatusOrphaned when no canonical child had a matching ExecutionParentHash, including the case where no canonical child had been observed yet. That made the recent- slots and filtered-slots lists show the half-blue "orphaned" indicator on Gloas blocks whose per-slot view still reported the payload as "Revealed" (canonical). Track whether any canonical child was seen and only return Orphaned when one exists but skips this payload, matching the slot detail logic in handlers/slot.go.
In EIP-7732 the beacon block body and the execution payload envelope are
gossiped on separate topics, so the payload-available event can fire
before the block-body event. When that happens:
1. processExecutionPayloadAvailableEvent runs SetExecutionPayload while
block.block is still nil. setBlockIndex(body=nil, payload) returns
early on the nil-body guard, so blockIndex.ExecutionHash stays zero.
block.executionPayload and block.hasExecutionPayload are still set.
2. processStreamBlock then ingests the body and calls
setBlockIndex(body, nil). Because the caller has no idea a payload
is already attached, ExecutionHash remains zero permanently.
Downstream comparisons that read blockIndex.ExecutionHash (finalization,
synchronizer, pruning, list-view getPayloadStatus) then compare zero
against the next block's ExecutionParentHash, conclude "payload not
included" and write PayloadStatusOrphaned to the DB. The per-slot detail
page reads bid.BlockHash from the body directly so it correctly reports
"Revealed", which is why the badges disagreed.
Have setBlockIndex fall back to block.executionPayload when no payload
arg is supplied, so a body arriving second still produces a complete
index. block.executionPayload is only set once SetExecutionPayload has
unmarshalled a valid envelope, so the fallback is safe.
barnabasbusa
force-pushed
the
bbusa/fix-list-view-payload-orphan-status
branch
from
7df8e04 to
5559e84
Compare
pk910
approved these changes
May 15, 2026
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
2 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.
Summary
Three small changes bundled together because (2) and (3) are required to build the image and exercise (1).
1. Fix: payload-status badge in list views (the actual bug)
`getPayloadStatus` in `services/chainservice_blocks.go` unconditionally returned `PayloadStatusOrphaned` when no canonical child had a matching `ExecutionParentHash`, including the case where no canonical child had been observed yet. That caused the recent-slots and filtered-slots list views to render the half-blue "orphaned" indicator on Gloas/ePBS blocks whose per-slot view (`handlers/slot.go:809-830`) correctly reported the payload as `Revealed` (canonical).
Track `hasCanonicalChild` and only return `PayloadStatusOrphaned` when a canonical child exists but skips this payload — matching the slot detail logic.
2. Bump Dockerfile golang base image `1.25.1` → `1.25.7`
Dependabot bumped `go.mod` from `go 1.25.1` to `go 1.25.7` last week (b770560) but the Dockerfile still pinned `golang:1.25.1`, so any clean `docker build` fails with:
```
go: go.mod requires go >= 1.25.7 (running go 1.25.1; GOTOOLCHAIN=local)
```
CI uses `go-version: 1.25.x` which auto-resolves, so this was invisible in CI.
3. Bump `github.com/ethpandaops/eth-das-guardian` `v0.1.0` → `v0.1.1`
The `v0.1.0` entry in sum.golang.org was poisoned on 2026-04-14: a failed Build Release workflow run created the `v0.1.0` tag, the sum DB indexed its content, and a subsequent retry force-moved the tag. The sum DB entry is immutable, so any clean `go mod download` fails:
```
verifying github.com/ethpandaops/eth-das-guardian@v0.1.0: checksum mismatch
downloaded: h1:r5pZ1eHHskZJ9JGSbp0E3u2pAI/loAC4q+u+Y58h7SY=
go.sum: h1:pEiRvtzPdF2xMjhiA/i+zmxIKd4uCsOTWxESa55zaJk=
```
Cut v0.1.1 of eth-das-guardian from the same main commit and bumped dora to use it. No code changes vs the intended v0.1.0 content.
Test plan