KnownSubgraphs polygon NPE2 endpoint name is 'npe2-mati' — possible typo vs deliberate 30-char hosted-service truncation, unverifiable since the hosted service sunset

[thedavidmeister]

Unit

CLI subgraph listing (crates/cli/src/subgraph/mod.rs) — AMT group g5-interpretercallermeta-v1.

Intent oracle

KnownSubgraphs::POLYGON docs: "Rain known subgraphs on polygon mainnet"; sibling entries use the -matic suffix (interpreter-registry-np-matic).

Observed behaviour

The polygon NPE2 endpoint is interpreter-registry-npe2-mati — mati, not matic, unlike its np-matic sibling.

Violated property (possible data typo)

Endpoint constants must exactly match the deployed subgraph names or subgraph ls/of_chain hand consumers a dead URL.

Refutation evidence (recorded, not adjudicated)

interpreter-registry-npe2-matic is 31 characters; The Graph hosted service capped subgraph names, so -mati may be a deliberate truncation to fit a 30-char limit. The hosted service (api.thegraph.com) has since been sunset, so the name can no longer be verified against a live deployment — every URL in this table is equally unreachable today, which may itself be worth a triage decision.

Triage framing (neutral)

Either the name is a faithful record of what was deployed (keep), or a typo that was never caught because the endpoint was already dead (fix or drop). Flagging; not adjudicating.

[thedavidmeister]

Cross-link for triage: #280 (closing #199) and #273 (closing #180) both delete the whole KnownSubgraphs table, including this interpreter-registry-npe2-mati constant, on the grounds that every endpoint in it is on the sunset hosted service and no live replacement is recorded anywhere in the org. If either merges, the string this issue is about no longer exists and the typo-vs-truncation question has no subject — neither PR closes this issue, since that is a triage call, not something a deletion can answer.

[thedavidmeister]

Ruling: no subject left on main — nothing to fix, flagging for a human close ruling

Checked main at 3a2e0cf2064c7be21e5e42e64c8f3dc26fc3ec1a (Merge pull request #283, tip at time of writing), in a fresh clone off origin/main.

The constant no longer exists

$ grep -rn "npe2-mati"          .   # NO MATCH
$ grep -rn "KnownSubgraphs"     .   # NO MATCH
$ grep -rn "interpreter-registry" . # NO MATCH
$ grep -rn "api.thegraph.com"   .   # NO MATCH
$ grep -rn "of_chain\|include_rain_subgraphs\|UnsupportedNetwork" --include="*.rs" --include="*.md" .  # NO MATCH
$ ls crates/cli/src/subgraph
ls: cannot access 'crates/cli/src/subgraph': No such file or directory

The unit this issue is filed against — crates/cli/src/subgraph/mod.rs — is deleted, along with the subgraph subcommand that printed the table, of_chain, Error::UnsupportedNetwork, and the test that pinned POLY_NPE2 = "...interpreter-registry-npe2-mati".

Deleted by commit 0a0346d ("Remove the KnownSubgraphs registry of sunset hosted-service endpoints"), merged as #280 today at 17:52 UTC; git merge-base --is-ancestor 0a0346d origin/main confirms it is in main's history. The concurrent duplicate #273 is CLOSED unmerged, so #280 is the one that landed.

The remaining subgraph references in the tree are unrelated: the metaboard subgraph client (caller-supplied URLs) and subgraph/ as source-only per CLAUDE.md. Nothing carries a hardcoded hosted-service endpoint any more.

The question itself is also unanswerable, independent of the deletion

The typo-vs-truncation call needs an oracle: what was actually deployed under that name. The only oracle was the hosted service at api.thegraph.com, which is sunset (#280 records a live 301 to error.thegraph.com/apierror.json), and an org-wide search for interpreter-registry finds no live replacement. Provenance adds circumstance but not an answer: the string entered in fc06a29 (2023-12-19, "update npe2 subgraphs"), the same commit that wrote the sibling with the full suffix as interpreter-registry-np-matic. Lengths are interpreter-registry-npe2-matic = 31, interpreter-registry-npe2-mati = 30, interpreter-registry-np-matic = 29 — consistent with a 30-char cap biting only the longer name, which is the refutation this issue already recorded, but it is circumstantial and not verifiable.

Disposition

No PR opened. There is no code on main a fix could touch, and answering a historical question is not a reason to restore deleted code — if live endpoints are ever recovered they belong in rain.metadata.deploy, per #280's reasoning and CLAUDE.md's library/deploy split, not as a restored table here.

Flagging ai:close-candidate. Not closing — whether a deletion counts as resolving this triage question is a human call, exactly as #280's body left it. The counter-case for keeping it open, stated plainly: this issue also asks the broader "every URL in this table is equally unreachable today, which may itself be worth a triage decision", and that broader question was answered by #280/#199/#180 rather than left open — so on my read nothing actionable remains here either.

[thedavidmeister]

🤖 ai:vetter
Stranded flag cleared: the ai:close-candidate label was live with no trusted producer comment stating a claim. Nothing could judge it (there is no claim) and nothing could clear it, while the label kept the issue out of the producer's backlog. Removing the label returns the issue to the producer. NO ruling is made on the issue.

This discards whatever intent applied the label, which was never recorded. To park an issue durably, rule it: human-rule-issue <repo> <n> keep-open "…" or human-close <repo> <n> "…". Those are the human's namespace — sacred, and no AI actor clears them.