[Bug] Panic during query if all configured DB endpoints have zero weight

[dm3ch]

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
v0.23.1

Config snippet:

    [store]
    [store.primary]
      connection = "postgresql://{{ $pgUser }}:{{ $pgPass }}@{{ $pgHost }}/{{ $pgDB }}"
      weight = 1
      pool_size = 10

Getting panic on query and following message in logs:

Click to expand!

Jul 17 19:31:00.035 INFO Graph Node version: 0.23.1 (2021-06-23)
Jul 17 19:31:00.035 INFO Reading configuration file `/etc/graph-node/config.toml`
Jul 17 19:31:00.172 INFO Starting up
Jul 17 19:31:00.172 INFO Trying IPFS node at: https://ipfs.network.thegraph.com/
Jul 17 19:31:00.269 INFO Creating transport, capabilities: archive, url: https://condescending-dijkstra:tassel-buffer-marina-wrist-uptake-colony@nd-217-782-475.p2pify.com, provider: mainnet-p2pify
Jul 17 19:31:00.472 INFO Successfully connected to IPFS node at: https://ipfs.network.thegraph.com/
Jul 17 19:31:01.477 INFO Creating transport, capabilities: archive, url: https://speedy-nodes-nyc.moralis.io/29e57ccd3ec48abbb7eeff39/eth/rinkeby/archive, provider: rinkeby-moralis
Jul 17 19:31:01.611 INFO Connecting to Postgres, weight: 0, conn_pool_size: 10, url: postgresql://postgres:HIDDEN_PASSWORD@postgres-postgresql/graph-node, pool: main, shard: primary
Jul 17 19:31:01.647 INFO Pool successfully connected to Postgres, pool: main, shard: primary, component: Store
Jul 17 19:31:01.668 INFO Setting up fdw, pool: main, shard: primary, component: ConnectionPool
Jul 17 19:31:01.669 INFO Running migrations, pool: main, shard: primary, component: ConnectionPool
Jul 17 19:31:01.670 INFO Migrations finished, pool: main, shard: primary, component: ConnectionPool
Jul 17 19:31:01.670 INFO Mapping primary, pool: main, shard: primary, component: ConnectionPool
Jul 17 19:31:01.687 INFO Connecting to Ethereum to get network identifier, capabilities: archive, provider: mainnet-p2pify
Jul 17 19:31:01.687 INFO Connecting to Ethereum to get network identifier, capabilities: archive, provider: rinkeby-moralis
Jul 17 19:31:01.807 INFO Connected to Ethereum, capabilities: archive, network_version: 1, provider: mainnet-p2pify
Jul 17 19:31:01.939 INFO Connected to Ethereum, capabilities: archive, network_version: 4, provider: rinkeby-moralis
Jul 17 19:31:01.942 INFO Creating LoadManager in disabled mode, component: LoadManager
Jul 17 19:31:01.945 INFO Starting JSON-RPC admin server at: http://localhost:8020, component: JsonRpcServer
Jul 17 19:31:01.946 INFO Starting GraphQL HTTP server at: http://localhost:8000, component: GraphQLServer
Jul 17 19:31:01.946 INFO Starting index node server at: http://localhost:8030, component: IndexNodeServer
Jul 17 19:31:01.946 INFO Starting metrics server at: http://localhost:8040, component: MetricsServer
Jul 17 19:31:01.946 INFO Started all subgraphs, component: SubgraphRegistrar
Jul 17 19:31:01.946 INFO Starting GraphQL WebSocket server at: ws://localhost:8001, component: SubscriptionServer
thread 'tokio-runtime-worker' panicked at 'attempt to calculate the remainder with a divisor of zero', store/postgres/src/deployment_store.rs:1039:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'tokio-runtime-worker' panicked at 'attempt to calculate the remainder with a divisor of zero', store/postgres/src/deployment_store.rs:1039:21
thread 'tokio-runtime-worker' panicked at 'attempt to calculate the remainder with a divisor of zero', store/postgres/src/deployment_store.rs:1039:21
thread 'tokio-runtime-worker' panicked at 'attempt to calculate the remainder with a divisor of zero', store/postgres/src/deployment_store.rs:1039:21
thread 'tokio-runtime-worker' panicked at 'attempt to calculate the remainder with a divisor of zero', store/postgres/src/deployment_store.rs:1039:21
thread 'tokio-runtime-worker' panicked at 'attempt to calculate the remainder with a divisor of zero', store/postgres/src/deployment_store.rs:1039:21

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
Start query node with only primary pg connection specified (without replicas) and weight 0.
Query any subgraph via graphql

What is the expected behavior?
It would be better to query master postgres connection in such case, or make config assertion that would be fail startup if weight equals zero

Current workaround:
Specify connection weight different than 0 (1 for example)

[azf20]

@leoyvens @lutter I don't know the internals well enough to say whether a check at startup or defaulting to master would make more sense here

[lutter]

I think a check and error message on startup makes the most sense in that situation

[azf20]

@lutter does this PR fix this or is it separate? #2749

[lutter]

Yes, that fixes it