You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consumers (e.g. dealbot) point at version-suffixed Goldsky subgraph slugs like pdp-explorer/mainnet311c / pdp-explorer/calibration311c. When the subgraph is redeployed, the deploy flow creates a new slug (...311d) and deletes the old one, so every consumer hardcoding the previous slug starts getting 404 Subgraph not found.
This just caused a ~6 day outage of dealbot's data-retention checks across mainnet and calibration:
The old mainnet311c / calibration311c endpoints were deleted → 404.
Dealbot's DataRetentionService.pollDataRetention() calls the subgraph first, so it aborted before emitting any metrics. SP approval stalled on "not enough samples" until the endpoints were repointed to 311d.
Request
Publish and maintain a stable, non-version-suffixed tag per network that always points at the current deployment, e.g.:
pdp-explorer-mainnet/prod/gn
pdp-explorer-calibration/prod/gn
Per the repo's own deploy doc (docs/subgraph/deployment.md), goldsky subgraph tag create/delete supports exactly this. The redeploy flow should:
Deploy the new versioned subgraph (...311d).
Wait for it to sync.
Move the stable tag (mainnet/calibration) to the new version (delete + recreate tag), rather than expecting consumers to chase the versioned slug.
Then consumers configure the stable tag once and survive redeploys.
Definition of done
Stable mainnet and calibration tags exist on Goldsky and resolve ({ _meta { block { number } } } returns 200).
Deploy doc / runbook updated so redeploys repoint the stable tag as a required step.
(Coordination) dealbot PDP_SUBGRAPH_ENDPOINT switched to the stable tag once available.
Context / refs
Old (deleted): .../subgraphs/pdp-explorer/mainnet311c/gn, .../calibration311c/gn → 404
Current (live): .../subgraphs/pdp-explorer/mainnet311d/gn, .../calibration311d/gn
Problem
Consumers (e.g. dealbot) point at version-suffixed Goldsky subgraph slugs like
pdp-explorer/mainnet311c/pdp-explorer/calibration311c. When the subgraph is redeployed, the deploy flow creates a new slug (...311d) and deletes the old one, so every consumer hardcoding the previous slug starts getting404 Subgraph not found.This just caused a ~6 day outage of dealbot's data-retention checks across mainnet and calibration:
311c→311d(alongside fix: missing listener address in data set #105 "missing listener address").mainnet311c/calibration311cendpoints were deleted → 404.DataRetentionService.pollDataRetention()calls the subgraph first, so it aborted before emitting any metrics. SP approval stalled on "not enough samples" until the endpoints were repointed to311d.Request
Publish and maintain a stable, non-version-suffixed tag per network that always points at the current deployment, e.g.:
pdp-explorer-mainnet/prod/gnpdp-explorer-calibration/prod/gnPer the repo's own deploy doc (
docs/subgraph/deployment.md),goldsky subgraph tag create/deletesupports exactly this. The redeploy flow should:...311d).mainnet/calibration) to the new version (delete + recreate tag), rather than expecting consumers to chase the versioned slug.Then consumers configure the stable tag once and survive redeploys.
Definition of done
mainnetandcalibrationtags exist on Goldsky and resolve ({ _meta { block { number } } }returns 200).PDP_SUBGRAPH_ENDPOINTswitched to the stable tag once available.Context / refs
.../subgraphs/pdp-explorer/mainnet311c/gn,.../calibration311c/gn→ 404.../subgraphs/pdp-explorer/mainnet311d/gn,.../calibration311d/gn