fix(indexer): populate ExecutionExtraData on Gloas+ blocks

[barnabasbusa]

Summary

• On Gloas+ (EIP-7732) the execution payload moves to a separate envelope, so body.ExecutionPayload is nil and getBlockExecutionExtraData(body) returns (nil, nil). The in-memory BlockBodyIndex.ExecutionExtraData was therefore always empty for post-Gloas blocks.
• This broke the NOT toggle on /blocks/filtered for the EL Extra Data filter: the inverted check short-circuits when blockExtraData == "" to "include empty/null extra data", so every cached block slipped through regardless of whether it matched the filter. The screenshot from glamsterdam-devnet-4 shows e.g. f.extra=buildoor/ethrex 12.0.0 with NOT checked still returning rows whose extra data is exactly buildoor/ethrex 12.0.0.
• Fix: read ExtraData from payload.Message.Payload.ExtraData next to the other execution fields, mirroring what writedb.go already does for the DB-write path. Finalized rows in the slots table were not affected because the write path was already correct — only the unfinalized cache filter saw empty extra data.

Test plan

• Reproduce the bug on glamsterdam-devnet-4: ?f.extra=ethrex&f.einvert=on includes ethrex rows.
• Local devnet repro on a Gloas+ chain confirms the same behavior, and the debug log shows blockExtraData="" for cached blocks pre-fix.
• After the fix: blockExtraData="ethrex 13.0.0", matches=true, block is correctly skipped; result set contains only non-matching extra data.
• Verify non-inverted filter still returns only matching rows.

[qu0b-reviewer]

🤖 qu0b-reviewer

Summary

The PR populates ExecutionExtraData from the SignedExecutionPayloadEnvelope.Payload.ExtraData field for Gloas+ (EIP-7732) blocks, which moved the execution payload out of the beacon block body. Without this, ExtraData filters on the blocks-filtered page silently drop all Gloas+ blocks since the field is always empty for them. The fix is correct in isolation but the delivery mechanism has a latent correctness gap that warrants flagging.

Issues

• 🟡 indexer/beacon/block.go:417–420 — setBlockIndex returns immediately when body == nil. For Gloas+ blocks, SetExecutionPayload is often called with block.block == nil (block body arrives via a different channel). In that case the ExtraData assignment at line 468 never executes, and the stale empty blockIndex.ExecutionExtraData persists. When GetOrUpdateBlockIndex() is later called (e.g., on the filtered blocks page), it short-circuits at line 497–498 because block.blockIndex is already set, so the ExtraData is still empty. This means Gloas+ blocks can still be returned by DB queries but silently fail the ExtraData filter, corrupting page results. The fix only works when SetExecutionPayload is called after SetBlock.

Suggestions

• indexer/beacon/block.go:463–469 — Consider making the payload branch idempotent so that re-calling it (e.g., on SetBlock or via GetOrUpdateBlockIndex) can backfill ExtraData from the stored block.executionPayload, rather than assuming it was already set:

  if payload != nil && payload.Message != nil && payload.Message.Payload != nil {
      // ... existing assignments ...
      if blockIndex.ExecutionExtraData == nil {
          blockIndex.ExecutionExtraData = payload.Message.Payload.ExtraData
      }
  }

  This is a safety net — the root fix (assigning from the envelope) is sound when called in the right order.

---

_{Reviewed @ 6b0f34a1
"If you can't measure it, you can't improve it." — Peter Drucker}