Custom/devnet issues: validator summary attribution fails, and /blobs panics with nil pointer dereference

[SyedMuhamadYasir]

Summary

We are running Dora against a private/custom Ethereum PoS devnet with Lighthouse as the consensus client and Reth as the execution client.

We are seeing two separate Dora application issues:

1. /validators/summary cannot correctly attribute validators to CL/EL combinations, even though Dora correctly detects the underlying clients on the dedicated client pages.
2. /blobs crashes with a nil pointer dereference in buildBlobsPageData.

I am reporting both together because they may indicate one of the following:

• unsupported assumptions for custom/devnets
• missing configuration for custom/devnets
• Dora bugs in attribution logic and nil handling

Environment

• Dora version: v1.22.2 (git-326465f)
• Consensus client: Lighthouse
• Execution client: Reth
• Network: private/custom PoS devnet
• Dora is connected to a working archive-primary source
• Dedicated client pages correctly show:
  • CL: Lighthouse
  • EL: Reth

Issue 1: Validator Summary attribution failure

Expected behavior

/validators/summary should either:

• correctly attribute validators to a CL/EL combination
• or gracefully degrade with a clear message that attribution is unavailable on this deployment

It should not show nonsensical values such as unknown: -1, and it should not collapse to "No Client Data Available" if Dora already knows the CL and EL clients elsewhere.

Actual behavior

• Dedicated client pages correctly identify Lighthouse and Reth.
• However, /validators/summary either:
  • shows unknown: -1
  • or shows "No Client Data Available"
• We tested multiple validator naming schemes, including:
  • generic names like node-a, node-b, node-c
  • explicit names like lighthouse-reth-1
  • explicit names like lighthouse-geth-1
• None of these made the summary page work correctly.

Why this looks like a Dora issue

This does not appear to be a raw client-detection problem, because the dedicated client pages are correct.

It looks like the validator summary feature uses a separate validator-to-client attribution path which is either:

• missing required metadata on custom/devnets
• making assumptions that do not hold on custom/devnets
• or has a bug in the attribution/classification logic

Questions

• Is validator-summary attribution on custom/devnets a known limitation?
• Is this considered a bug?
• Is there additional supported configuration required beyond validator_names.yaml?
• If extra metadata/config is required, what is the intended mechanism?

Issue 2: /blobs panics with nil pointer dereference

Expected behavior

If the network has no blob data, /blobs should render a clean empty state such as:

• "No blob data available"
• "No blob-carrying transactions observed"
• or similar

It should not panic.

Actual behavior

Requesting /blobs causes a page error and Dora reports:

• page call 2 panic: runtime error: invalid memory address or nil pointer dereference

Stack trace points to:

• github.com/ethpandaops/dora/handlers.buildBlobsPageData
• handlers/blobs.go
• around line 72

Relevant stack excerpt

panic: runtime error: invalid memory address or nil pointer dereference

github.com/ethpandaops/dora/handlers.buildBlobsPageData
  /home/runner/work/dora/dora/handlers/blobs.go:72
github.com/ethpandaops/dora/handlers.getBlobsPageData.func1
  /home/runner/work/dora/dora/handlers/blobs.go:44
github.com/ethpandaops/dora/services.(*FrontendCacheService).processPageCall.func1
  /home/runner/work/dora/dora/services/frontendcache.go:211

Why this looks like a Dora issue

This looks like missing nil or empty-state handling inside the blobs page handler. The page appears to assume some blob-related data structure exists and dereferences it instead of returning an empty page.

Questions

• Is /blobs on custom/devnets a known unsupported path?
• Is this considered a bug?
• Does Dora expect specific blob-supporting API/data/indexing beyond a standard beacon node?
• Should Dora now be using /eth/v1/beacon/blobs/{block_id} instead of older blob-sidecar assumptions?

Notes

• This deployment is otherwise healthy.
• The archive BN/EL source is working.
• Dedicated client pages are working.
• The failures appear isolated to:
  • validator-summary attribution logic
  • blobs page nil handling or empty-state behavior

Request

Please clarify whether these are:

• known limitations on custom/devnets
• actual bugs
• or missing supported configuration

If these are bugs, guidance on the intended attribution source for validator summary and the intended no-data behavior for /blobs would be very helpful.