@subql/node-ethereum init fails on Polkadot Hub RPCs (earliest -> 0x0 -> null)

[pasevin]

Summary

@subql/node-ethereum fails during init() on Polkadot Hub RPCs with:

Getting genesis block returned null from tag: earliest

This blocks indexer startup before indexing begins.

Why this happens

In subql-ethereum/packages/node/src/ethereum/api.ethereum.ts, init() calls getGenesisBlock(chainId).
For most chains, getGenesisBlock() uses this.client.getBlock('earliest').

With ethers v5, getBlock('earliest') is normalized to eth_getBlockByNumber('0x0', false).
On Polkadot Hub RPCs, 0x0 returns null, so SubQuery throws and exits.

Affected networks (verified)

• Polkadot Hub mainnet (chainId: 420420419) — fails
• Polkadot Hub testnet (chainId: 420420417) — fails

Not affected (verified)

• Moonbeam (1284) — passes
• Moonriver (1285) — passes
• Moonbase Alpha (1287) — passes

Additional observed behavior on Polkadot Hub RPCs

• eth_getBlockByNumber('earliest', false) returns non-null
• eth_getBlockByNumber('0x0', false) returns null
• ethers.getBlock('earliest') returns null (because it requests 0x0)

First existing substrate heights that return EVM block number 0x0:

• Mainnet: 11405258
• Testnet: 4367913

Minimal repro

import { providers } from 'ethers';

const p = new providers.JsonRpcProvider('https://services.polkadothub-rpc.com/mainnet');
await p.getNetwork();
const block = await p.getBlock('earliest');
console.log(block); // null

Equivalent SubQuery init check behavior:

const b = await provider.getBlock('earliest');
if (b === null) throw new Error('Getting genesis block returned null from tag: earliest');

Request

Could @subql/node-ethereum make genesis init robust for chains where 0x0 is not directly available via EVM RPC adapter (e.g. Polkadot Hub)?

Potential approaches:

1. Avoid strict dependency on getBlock('earliest' -> 0x0) for startup validation.
2. Add chain-specific non-zero genesis tag mapping (similar to existing BEVM Canary special-case).
3. Fallback logic when 'earliest' resolves to null but the endpoint is otherwise healthy.

Thanks — happy to run additional tests if needed.

[pasevin]

Follow-up: second crash with unfinalized blocks enabled on v6.3.2-0

A node operator tested v6.3.2-0 on Polkadot Hub mainnet and confirmed the genesis init fix works — startup no longer fails with the earliest tag error.

However, when running with unfinalized blocks and historical state enabled (i.e. without --disable-historical), the node crashes shortly after startup during unfinalized block processing:

2026-02-22T18:09:21.515Z <UnfinalizedBlocks> INFO Unfinalized blocks is enabled
2026-02-22T18:09:21.638Z <UnfinalizedBlocks> INFO Processing unfinalized blocks
2026-02-22T18:09:21.866Z <subql-node> ERROR undefined Error: Node failed to start
Cause: TypeError: Cannot read properties of null (reading 'number')

Analysis

The crash is a null-dereference on a block object's .number property. The likely code path is the unfinalized blocks processing calling getHeaderForHeight() or getHeaderForHash() via BlockchainService, which passes the result to ethereumBlockToHeader(block) → block.number without a null guard.

This is the same family of issue: Polkadot Hub RPCs return null for certain block-by-height/hash queries that standard EVM chains handle, and the code assumes a non-null block.

Workaround

Running with --disable-historical (which also disables unfinalized blocks) avoids this second crash. Our local testing with --disable-historical on v6.3.2-0 passed cleanly for both Polkadot Hub mainnet and testnet.

Ask

Could null guards be added to block fetches in the unfinalized blocks / blockchain service path as well? Specifically:

• BlockchainService.getFinalizedHeader()
• BlockchainService.getHeaderForHeight()
• BlockchainService.getHeaderForHash()
• ethereumBlockToHeader() (or its callers)

These currently assume the block object is always non-null.