Describe the bug
Self-referencing table embeds behave inconsistently depending on whether the relationship hint is a column name or a foreign key constraint name.
Table:
CREATE TABLE public.lab (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
name text,
type text,
parent uuid REFERENCES lab(id) ON DELETE CASCADE, -- constraint: lab_parent_fkey
main uuid REFERENCES lab(id) ON DELETE CASCADE -- constraint: lab_main_fkey
);
Case 1 — column name hint (!parent)
const query = supabase.from("lab").select("*,lab!parent(name,id)").eq("type", "board");
- Runtime response: correct,
lab is returned as an array of children.
- Inferred type: incorrect —
lab is typed as { name: string | null; id: string } | null instead of an array.
Case 2 — foreign key constraint name hint (!lab_parent_fkey)
const query = supabase.from("lab").select("*,lab!lab_parent_fkey(name,id)").eq("type", "board");
- Inferred type: correct —
lab: { name: string | null; id: string }[].
- Runtime response: fails with PGRST200:
{
"code": "PGRST200",
"details": "Searched for a foreign key relationship between 'lab' and 'lab' using the hint 'lab_parent' in the schema 'public', but no matches were found.",
"hint": null,
"message": "Could not find a relationship between 'lab' and 'lab' in the schema cache"
}
Note that the hint received by PostgREST is lab_parent, not lab_parent_fkey as written in the query. Confirmed via the browser Network tab that the actual outgoing request also has the truncated hint — this is not a typo in our code. The _fkey suffix appears to be stripped somewhere in the select-string building for self-referencing embeds.
Expected behavior
lab!lab_parent_fkey(name,id) should send the full constraint name lab_parent_fkey to PostgREST and resolve as one-to-many (array).
lab!parent(name,id) should infer the correct array type at compile time, matching runtime behavior.
Library affected
supabase-js
Reproduction
No response
Steps to reproduce
- Create a table with two self-referencing foreign keys as above.
- Run both queries shown.
- Compare inferred TS types vs actual runtime response, and inspect the outgoing request URL for Case 2.
System Info
supabase-js version: 2.110.2
Used Package Manager
pnpm
Logs
No response
Validations
Describe the bug
Self-referencing table embeds behave inconsistently depending on whether the relationship hint is a column name or a foreign key constraint name.
Table:
Case 1 — column name hint (
!parent)labis returned as an array of children.labis typed as{ name: string | null; id: string } | nullinstead of an array.Case 2 — foreign key constraint name hint (
!lab_parent_fkey)lab: { name: string | null; id: string }[].{ "code": "PGRST200", "details": "Searched for a foreign key relationship between 'lab' and 'lab' using the hint 'lab_parent' in the schema 'public', but no matches were found.", "hint": null, "message": "Could not find a relationship between 'lab' and 'lab' in the schema cache" }Note that the hint received by PostgREST is
lab_parent, notlab_parent_fkeyas written in the query. Confirmed via the browser Network tab that the actual outgoing request also has the truncated hint — this is not a typo in our code. The_fkeysuffix appears to be stripped somewhere in the select-string building for self-referencing embeds.Expected behavior
lab!lab_parent_fkey(name,id)should send the full constraint namelab_parent_fkeyto PostgREST and resolve as one-to-many (array).lab!parent(name,id)should infer the correct array type at compile time, matching runtime behavior.Library affected
supabase-js
Reproduction
No response
Steps to reproduce
System Info
Used Package Manager
pnpm
Logs
No response
Validations