Grafting onto a pruned base silently loses data

[incrypto32]

Bug

Graft::validate (graph/src/data/subgraph/mod.rs:549) checks that the graft block is below base.latest_block, above the reorg threshold, and that the base is healthy. It does not check that the graft block is at or above base.earliest_block_number.

When the base has pruned past the graft block, the copy step's filter (WHERE lower(block_range) <= target_block) finds no rows for mutable entities whose [lo, hi) versions were deleted by pruning. The destination is silently created missing all pre-graft mutable state. Immutable entities are unaffected — their [lo, ∞) ranges are never pruned.

The destination reports synced: true, healthy: true and returns wrong data with no error.

Scope

Affects any subgraph with:

• indexerHints.prune enabled on the base
• A graft.block older than base.earliest_block_number at deploy time
• At least one mutable entity updated between the graft block and the prune horizon