graphman rewind resolves the active deployment instead of the targeted sgdNNN when duplicate deployments exist #6365
Description
Bug report
graphman rewind uses DeploymentHash (Qm hash) instead of DeploymentId (sgdNNN) when calling the store's rewind/truncate methods. This causes it to always operate on the active deployment, regardless of which specific sgdNNN was requested.
Related: #5167 — this is the root cause of that issue.
Root cause
In node/src/manager/commands/rewind.rs, the rewind loop (L161-185) passes loc.hash.clone() to subgraph_store.rewind():
subgraph_store.rewind(loc.hash.clone(), block_ptr)?; // L174
subgraph_store.truncate(loc.hash.clone(), start_block_ptr)?; // L178SubgraphStore::rewind() then calls self.store(&id) → self.site(&id) → find_active_site(), which filters on active = true. The DeploymentId carried by the locator is discarded.
Meanwhile, the other phases of the same command correctly use the locator's ID:
| Phase | Resolution | Target |
|---|---|---|
| Safety check (L128-145) | locate_site(locator) — by ID |
requested sgdNNN |
| Pause (L148-150) | pause_or_resume(locator) — by ID |
requested sgdNNN |
| Rewind (L174) | rewind(loc.hash) → find_active_site() |
active deployment |
| Truncate (L178) | truncate(loc.hash) → find_active_site() |
active deployment |
| Resume (L188-190) | pause_or_resume(locator) — by ID |
requested sgdNNN |
Consequences
When the same Qm hash exists on two schemas (e.g. after graphman copy):
- Rewinding the inactive copy is impossible — the rewind silently hits the active deployment instead
- The paused deployment is not the one being rewound — pause targets the requested sgdNNN, but rewind targets the active deployment, so the active deployment gets rewound without being paused first
- Batch rewind rewinds the same deployment multiple times — each sgdNNN sharing a Qm hash triggers a rewind of the same active deployment (as reported in [Bug] graphman rewind repeatedly rewinds the same SG #5167)