[dimitrovmaksim]

Fixes #6751

Problem

DeploymentStore::get_proof_of_indexing only checked the requested block against the subgraph head. For a block below earliest_block_number, pruning has removed Poi$ versions, so the query returned an incomplete set of causality-region digests. ProofOfIndexingFinisher hashed them into a well-formed but wrong POI, returned as a normal result. publicProofsOfIndexing goes through the same function.

Fix

After querying Poi$, read earliest_block_number and return an error if the queried block is below it. The error text is the one GraphQL queries already return for this case (DeploymentState::block_queryable).

The check runs after the query on purpose. Pruning commits the new earliest_block_number before it deletes any rows, so if the query saw deleted rows, the read that follows sees the raised earliest block. A check before the query leaves a window where a prune commits between the check and the query. A comment in do_prune records the ordering this relies on.

Behaviour changes

• Pruned blocks: proofOfIndexing and publicProofsOfIndexing return null instead of a wrong POI.
• Blocks below the start block: earliest_block_number starts at startBlock - 1, so blocks below it now also return null, on deployments that were never pruned too. Before, they returned a POI hashed from an empty Poi$ set. Both cases are treated the same way: the store has no data for the block. This matches DeploymentState::block_queryable and needs no new state.
• Clients only see null: the index-node resolver logs store errors and returns null, as it already does for a block above the head. The reason and the earliest block are in the graph-node log; the earliest block is also available as indexingStatuses { chains { earliestBlock } }.

Operator note

With indexerHints.prune: auto, a deployment keeps GRAPH_MIN_HISTORY_BLOCKS blocks of history (default 2 * ETHEREUM_REORG_THRESHOLD = 500), and pruning runs once that is exceeded by GRAPH_STORE_HISTORY_SLACK_FACTOR (default 1.2). That is shorter than an epoch on every chain. Once the current epoch's start block has been pruned, graph-node now returns null, and indexer-agent refuses a normal allocation close with IE067 ("POI not available for deployment at current epoch start block"). Before this change it submitted a wrong POI that could be disputed.

To keep closing allocations normally, retain at least one epoch of history for the chain: raise GRAPH_MIN_HISTORY_BLOCKS, or set it per deployment with graphman prune set.

Tests

• graft::prune: after a real prune (Rebuild and Delete strategies) moves the earliest block to 3, a POI at block 2 is an error naming block 3, and block 3 still returns a POI.
• graft::poi_below_start_block: a deployment created with a start block has earliest_block_number equal to it; a POI below it is an error, and at it returns a POI.

Both tests fail without the fix: the store returns Some(..) for the lower block.