khedra daemon requires reachable mainnet RPC, blocks headless / container / CI deployments

[MysticRyuujin]

Summary

khedra daemon requires a reachable mainnet RPC that returns chainId: 1 on every startup via install.Configured(). This makes khedra unusable in hermetic / air-gapped / CI / container-with-no-internet environments — and specifically blocks the kurtosis ethereum-package from migrating to khedra for its trueblocks integration.

Background

I'm integrating chifra into ethpandaops/ethereum-package (the kurtosis Ethereum testnet runner). A devnet spun up by ethereum-package is fully isolated: no public network access guaranteed, the only chain that exists is whatever the user is testing (typically a local kurtosis chain or a shadowfork).

khedra would be a great fit functionally — single process, ServiceManager runs API + scraper + monitor together, much cleaner than chaining chifra daemon and chifra scrape. But the mainnet validation makes it a non-starter.

Current behavior

Even with this config:

chains:
  mainnet:
    rpcs:
      - "http://localhost:8545"
    enabled: false       # ← explicitly disabled
    chainId: 1
  kurtosis:
    rpcs:
      - "http://my-devnet-rpc:8545"
    enabled: true
    chainId: 3151908

services:
  scraper:
    enabled: true
  api:
    enabled: true
    port: 8080

khedra daemon will:

1. Call install.Configured()
2. Find the mainnet block, attempt to reach its RPC
3. The RPC fails (or returns chainId != 1) since there's no real mainnet node available
4. Fall back to the browser-based setup wizard
5. Daemon never starts

Setting mainnet.enabled: false doesn't help — the validation still runs unconditionally.

Why this is wrong

If mainnet.enabled: false, khedra explicitly isn't going to do anything with mainnet — no scraping, no monitoring, no API serving against it. The mainnet RPC reachability check has no functional purpose in that mode; it's effectively asserting "you have internet" for users who've already told khedra they don't need mainnet.

For a deployment shape khedra clearly wants to support (containers, services, etc. — there's a khedra daemon command for a reason), this gating on a chain the operator has disabled is unjustified friction.

Proposed fix

Three options in order of cleanliness:

Option A (recommended): skip the reachability check for any chain where enabled: false.

If the user has explicitly disabled a chain, don't validate its RPC. The chainId-must-equal-1 check is preserved when mainnet.enabled: true.

Option B: gate validation on a flag / env var.

khedra daemon --skip-validation or TB_KHEDRA_SKIP_VALIDATION=true. Explicit opt-out, no behavior change for existing setups. Operators in CI / container contexts know what they're doing.

Option C: a "headless mode" config setting.

general:
  headless: true   # skip install wizard prerequisites; trust the config

When set, install.Configured() either passes immediately or only checks for the existence of required fields (not RPC reachability). Same intent as B but lives in config instead of CLI/env, which matches how the rest of khedra's settings work.

Workaround we're using meanwhile

We're sticking with chifra daemon (one process, no auto-scrape — users POST /scrape if they want indexing) instead of migrating to khedra. We'd prefer to migrate the moment khedra works headlessly: the unified ServiceManager and khedra daemon are objectively cleaner than running chifra daemon + chifra scrape separately.

If any of options A/B/C lands, the relevant kurtosis launcher change is small and we'll happily migrate.

Related

• Companion issue on chifra side: TrueBlocks/trueblocks-core#4044 (about IsNodeArchive being misnamed). Independent of this issue — khedra still inherits chifra's check — but mentioning for context.