-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Description
Description
We are attempting to configure multiple indexer nodes, each dedicated to indexing a specific chain, within a multi-chain environment. To minimize resource consumption, we are utilizing the pool_size = 0 configuration option (introduced in PR #3513) for any shard connections that are not relevant to the current index node.
The documentation states that the primary shard is shared between chains. When a node starts, it connects to the primary shard, which in turn seems to discover the existence of all configured shards.
The intention of setting pool_size = 0 is to avoid establishing unnecessary Postgres connections for these unused shards. However, the node startup process appears to fail later when attempting to use or initialize a component (specifically the BlockStore) that expects a connection pool for every configured shard, even when its pool size is zero.
The log clearly shows the shard being ignored as expected, but a later component fails because a pool for the shard is missing:
Oct 12 21:00:05.465 WARN pool size for shard eth_chain is 0, ignoring this shard, shard: eth_chain
...
thread 'main' panicked at node/src/store_builder.rs:203:14:
Creating the BlockStore works: InternalError("there is no pool for shard eth_chain")
Expected Behavior
If a shard is configured with pool_size = 0, the Graph Node should:
- Log a warning indicating the shard is ignored (which currently happens).
- Successfully complete startup and operate without requiring or attempting to establish a connection pool for that shard, especially during components like BlockStore initialization.
This behavior would allow us to list all potential shards in a config.toml (even though we do not understand why we need to do this) but only consume Postgres connections for the shards actively used by the specific node instance.
Steps to Reproduce
- Configure a config.toml with the standard primary shard and at least two chain-specific shards (e.g., optimism and eth_chain).
- Set
pool_size = 0for one of the chain-specific shards (e.g., eth_chain). - Start Graph Node using this configuration.
Environment
Graph Node Version: 0.41.0 (from the logs)
Docker
PostgreSQL Version: 18
Relevant Configuration Snippet
# Main node shard, used by this indexer
[store.primary]
connection = "..."
pool_size = 10
# Chain shard for this indexer
[store.optimism]
connection = "..."
pool_size = 10
# Chain shard for an *other* indexer node, but included here to satisfy configuration discovery
[store.eth_chain]
connection = "..." # This connection URL doesn't even need to be valid/reachable, as we expect it to be ignored
pool_size = 0
Relevant log output
Oct 12 21:00:05.465 WARN pool size for shard eth_chain is 0, ignoring this shard, shard: eth_chain
...
thread 'main' panicked at node/src/store_builder.rs:203:14:
Creating the BlockStore works: InternalError("there is no pool for shard eth_chain")IPFS hash
No response
Subgraph name or link to explorer
No response
Some information to help us out
- Tick this box if this bug is caused by a regression found in the latest release.
- Tick this box if this bug is specific to the hosted service.
- I have searched the issue tracker to make sure this issue is not a duplicate.
OS information
Linux