Observation, found while implementing #8132 (PR #8263). Not fixed there: #8132's ruling scopes it to the shared predicate in packages/types, and this line sits in packages/rest/src/rest-server.ts, where #8039 lands next round. Filed unassigned so the two do not collide.
What was measured
#8132 taught the shared looksLikeInternalErrorLeak the Postgres missing-relation phrasing, anchored on the template Postgres actually emits — a QUOTED identifier:
/\b(?:relation|column)\s+["'`][^"'`]+["'`]\s+does not exist/i
The anchor is load-bearing: without it, does not exist is ordinary business English and the predicate would start replacing legitimate answers with Internal server error. Two negative cases in packages/types/src/error-leak.test.ts pin that.
rest-server.ts:1337 answers a closely related question with the loose form instead:
const looksLikeMissingRelation =
lower.includes('no such table') ||
(lower.includes('relation') && lower.includes('does not exist')) ||
lower.includes('table not found');Those two conjuncts need not be the same sentence, so a message merely containing both words matches. This relation does not exist in the diagram is a concrete example — it is one of the negative cases the new predicate deliberately rejects, and the same string is a positive here.
Why it may matter
looksLikeMissingRelation gates a 404-vs-500 decision. A match with missingRelationIsObject(raw, object) false returns DATA_STORE_FAULT() — a sanitised 500 DATABASE_ERROR. So a business message that happens to use both words could be re-labelled a data-store fault rather than getting its real verdict.
Deliberately NOT asserted
I did not measure a reachable production path that produces such a message at this call site, and the branch's own comment (#5462) explains that the loose reading is a legacy safety net whose primary producer is the registry gate far above. So this is drift between two spellings of one question, not a demonstrated live bug — the severity call belongs to triage, not to me.
Whoever picks this up should decide whether the two questions should share the anchored helper at all, or whether the exclusion-direction width is correct here on purpose (relation-sub-object.ts documents exactly that "two widths, on purpose" reasoning for a neighbouring pair).
Backlink: #8132, PR #8263.
Observation, found while implementing #8132 (PR #8263). Not fixed there: #8132's ruling scopes it to the shared predicate in
packages/types, and this line sits inpackages/rest/src/rest-server.ts, where #8039 lands next round. Filed unassigned so the two do not collide.What was measured
#8132 taught the shared
looksLikeInternalErrorLeakthe Postgres missing-relation phrasing, anchored on the template Postgres actually emits — a QUOTED identifier:The anchor is load-bearing: without it,
does not existis ordinary business English and the predicate would start replacing legitimate answers withInternal server error. Two negative cases inpackages/types/src/error-leak.test.tspin that.rest-server.ts:1337answers a closely related question with the loose form instead:Those two conjuncts need not be the same sentence, so a message merely containing both words matches.
This relation does not exist in the diagramis a concrete example — it is one of the negative cases the new predicate deliberately rejects, and the same string is a positive here.Why it may matter
looksLikeMissingRelationgates a 404-vs-500 decision. A match withmissingRelationIsObject(raw, object)false returnsDATA_STORE_FAULT()— a sanitised 500DATABASE_ERROR. So a business message that happens to use both words could be re-labelled a data-store fault rather than getting its real verdict.Deliberately NOT asserted
I did not measure a reachable production path that produces such a message at this call site, and the branch's own comment (#5462) explains that the loose reading is a legacy safety net whose primary producer is the registry gate far above. So this is drift between two spellings of one question, not a demonstrated live bug — the severity call belongs to triage, not to me.
Whoever picks this up should decide whether the two questions should share the anchored helper at all, or whether the exclusion-direction width is correct here on purpose (
relation-sub-object.tsdocuments exactly that "two widths, on purpose" reasoning for a neighbouring pair).Backlink: #8132, PR #8263.