wormhole collect-rewards fails with "GraphQL errors: database query error" on Subsquid query, consistently, across CLI versions

[vaudois]

markdown

Description

quantus wormhole collect-rewards consistently fails at "Step 2: Querying Subsquid for pending transfers..." with:

❌ Error: Error: Error: GraphQL errors: database query error
⏱️  Failed after 5-6s

This has been reproducing for several hours, across:

• CLI v2.2.2 (original)
• CLI v2.3.0 (upgraded via cargo install --git ... --tag v2.3.0, rebuilt ZK circuit binaries from scratch - same error after)

What I've ruled out

1. Not a total Subsquid outage - a basic introspection query works fine:

   curl -s -X POST https://sub2.quantus.com/v1/graphql -H "Content-Type: application/json" -d '{"query":"{ __typename }"}'
   # -> {"data":{"__typename":"query_root"}}

2. Not a generic schema/type bug on the transfer table - a structurally similar query (same _like on to_hash/from_hash, same transfer_bool_exp shape, real block-height range) works fine with a dummy prefix:

   curl -s -X POST https://sub2.quantus.com/v1/graphql -H "Content-Type: application/json" -d '{
     "query": "query($where: transfer_bool_exp!, $limit: Int!, $offset: Int!) { transfers: transfer(where: $where, limit: $limit, offset: $offset) { id block_id block { height } timestamp } meta: transfer_aggregate(where: $where) { aggregate { count } } }",
     "variables": {
       "where": {"_or": [{"to_hash": {"_like": "ab%"}}, {"from_hash": {"_like": "ab%"}}], "block": {"height": {"_gte": 1, "_lte": 999999}}},
       "limit": 10, "offset": 0
     }
   }'
   # -> returns real data, aggregate count 2629

So the Subsquid endpoint and the transfer table are healthy for structurally similar queries - something specific to the real query collect-rewards builds for this wormhole address is failing.

Suspicion

Possibly the actual query ends up with a very large _or array (one condition per nullifier/hash prefix to check) if the wormhole has accumulated many small transfers over time, and hits a Postgres complexity/timeout limit that surfaces as this generic Hasura-style error.

Environment

• quantus-node: mainnet, --validator
• quantus-cli: 2.3.0 (built from source, cargo install --git https://github.com/Quantus-Network/quantus-cli --tag v2.3.0)
• Subsquid URL: default (https://sub2.quantus.com/v1/graphql)
• OS: Ubuntu 22.04

Happy to provide the wormhole address / more diagnostics if useful (not posting it publicly here for privacy).