Bug report
IndexNodeResolver::block_ptr_for_number returns Ok(None) without logging when the network isn't in the node's BlockchainMap. blockHashFromNumber on a node without that network is therefore an instant null, and from outside that looks the same as "block not found".
The common case is a query node. A node whose id matches [general] query gets Networks::noop() in from_config_inner, so it has no chains at all. It still serves the index-node API on 8030 and answers version, and nothing at startup says it came up query-only.
indexer-agent pointed at that node reports IE070 no data returned, and people go chasing the RPC and the EBO subgraph. It's the same unanswered question as #4880.
resolve_cached_ethereum_calls already logs Failed to fetch cached Ethereum calls; nonexistent network for the same situation, so blockHashFromNumber is the odd one out.
Repro on v0.45.0:
[general] query = "index_node_0" with --node-id index_node_0, then { blockHashFromNumber(network: "mainnet", blockNumber: 25961537) } returns null with query_time_ms: 0 and no WARN
- same result on a normal index node with
network: "nosuchchain"
Suggestion: a WARN (or a GraphQL error) naming the network and this node's id when the network isn't configured here, and an INFO at startup when a node comes up query-only. Same idea as #6718 for the ingestor.
Relevant log output
INFO Query timing (GraphQL), block: 0, query_time_ms: 0, variables: null, query: { version { version } blockHashFromNumber(network: "mainnet", blockNumber: 25961537) } , subgraph_id: indexnode, component: IndexNodeServer
IPFS hash
No response
Subgraph name or link to explorer
No response
Some information to help us out
OS information
macOS
Bug report
IndexNodeResolver::block_ptr_for_numberreturnsOk(None)without logging when the network isn't in the node'sBlockchainMap.blockHashFromNumberon a node without that network is therefore an instantnull, and from outside that looks the same as "block not found".The common case is a query node. A node whose id matches
[general] querygetsNetworks::noop()infrom_config_inner, so it has no chains at all. It still serves the index-node API on 8030 and answersversion, and nothing at startup says it came up query-only.indexer-agent pointed at that node reports IE070
no data returned, and people go chasing the RPC and the EBO subgraph. It's the same unanswered question as #4880.resolve_cached_ethereum_callsalready logsFailed to fetch cached Ethereum calls; nonexistent networkfor the same situation, soblockHashFromNumberis the odd one out.Repro on v0.45.0:
[general] query = "index_node_0"with--node-id index_node_0, then{ blockHashFromNumber(network: "mainnet", blockNumber: 25961537) }returnsnullwithquery_time_ms: 0and no WARNnetwork: "nosuchchain"Suggestion: a WARN (or a GraphQL error) naming the network and this node's id when the network isn't configured here, and an INFO at startup when a node comes up query-only. Same idea as #6718 for the ingestor.
Relevant log output
INFO Query timing (GraphQL), block: 0, query_time_ms: 0, variables: null, query: { version { version } blockHashFromNumber(network: "mainnet", blockNumber: 25961537) } , subgraph_id: indexnode, component: IndexNodeServerIPFS hash
No response
Subgraph name or link to explorer
No response
Some information to help us out
OS information
macOS