Data API: all RPC calls return 404 PGRST202 (function not found) while table access and OpenAPI spec still work

[Diadz27]

Subject: Data API — all RPC calls return 404 PGRST202 (function not found) while table access and OpenAPI spec still work

Project ref: shpejvdbsplkqipfuuay
Region: ap-northeast-1 | PostgREST version: 14.5 (per pg_stat_activity)

Summary
Since 2026-10-22, EVERY RPC call to the Data API on this project returns HTTP 404 with
PGRST202: "Searched for the function public. ... but no matches were found in the schema cache."
Table access (GET/POST /rest/v1/

) works normally, and GET /rest/v1/ (OpenAPI spec)
still lists all functions with correct signatures.

Reproduction (curl)
curl -i -X POST 'https://shpejvdbsplkqipfuuay.supabase.co/rest/v1/rpc/login'
-H 'apikey: '
-H 'Content-Type: application/json'
-d '{"p_username":"x","p_password":"y","p_hwid":"z"}'

HTTP/1.1 404 Not Found
{"code":"PGRST202",
"details":"Searched for the function public.login with parameter {...}, but no matches were found in the schema cache.",
"hint":null,
"message":"Could not find the function public.login({...}) in the schema cache"}

What I have verified1. Affects 100% of functions: also zero-argument functions (e.g. admin_list_users()), functions
created AFTER the incident, and functions in a newly created + newly exposed schema (app_api).
2. Same result with the publishable key (anon) and with the secret key (service_role).
3. Table endpoints work normally: RLS behaves correctly, service_role sees all rows.
4. GET /rest/v1/ returns the OpenAPI spec listing all 20 functions with correct signatures.
5. NOTIFY pgrst, 'reload schema'; does not help. DDL (CREATE TABLE / DROP TABLE) does not help.
6. pg_stat_activity shows "PostgREST 14.5" connected as role "authenticator" (NOINHERIT).
7. In Postgres the functions exist with correct signatures and grants
(PUBLIC/anon/authenticated/service_role); has_function_privilege('authenticator',
'public.login(text,text,text)','EXECUTE') = true. Owners are unchanged (postgres).
8. BEFORE 2026-10-22 RPC calls worked fine on this project (admin_list_users returned data
through the Data API with the legacy anon key).
9. The change coincides with SQL migrations applied through the Management API
(CREATE OR REPLACE FUNCTION changing a function signature + GRANT/REVOKE on functions).

Request
Could you please check and refresh the schema cache of the Data API for this project
(or restart the PostgREST service)? Failing that, please advise how to recover function
resolution — we currently have to route authentication through an Edge Function as a workaround.

Impact: the desktop app authenticates via POST /rest/v1/rpc/login, so users cannot sign in
until this is resolved.

[cekuu35]

Your troubleshooting already isolates the interesting part: newly created functions 404 too, and neither NOTIFY pgrst, 'reload schema' nor DDL moves anything. That combination means the schema cache is not merely stale ? the reload channel itself is wedged. If PostgREST were just holding an old cache, a fresh NOTIFY (or any tracked DDL event) would still refresh it, and a function created after the incident would appear on the next reload. Neither happening points to the LISTEN connection that receives reload events having died during the migration window, so the runtime keeps resolving against a snapshot it can no longer update ? and that snapshot predates your signature changes, which is exactly why calls that worked before 2026-10-22 now match nothing.

A quick way to confirm it is a frozen cache rather than a privilege-resolution issue: compare the parameter shape the API error echoes with what the live catalog has ?

select p.proname, pg_get_function_identity_arguments(p.oid)
from pg_proc p join pg_namespace n on n.oid = p.pronamespace
where n.nspname = 'public' and p.proname = 'login';

If the live signature differs in argument types (not just names) from what the API says it searched for, the API is resolving against the pre-migration definition ? a frozen cache, not a missing grant. A pure EXECUTE privilege problem would not touch brand-new zero-argument functions, and would not survive the service_role key the way yours does.

Since this is hosted, you cannot restart PostgREST directly, but you can force a redeploy without touching data:

1. Dashboard ? Settings ? API ? change any PostgREST-affecting setting and save ? e.g. temporarily add app_api to "Exposed schemas", save, then revert. Saving redeploys the Data API with a fresh listener and a rebuilt cache ? the self-service equivalent of a restart.
2. If a redeploy does not rebuild function resolution, the fallback is a Support ticket asking for a PostgREST restart on your project ref ? your diagnostics above are already complete enough to paste as-is.

Two things worth ruling out while you wait, since the migration touched GRANT/REVOKE:

-- PostgREST SET ROLEs from authenticator to these; all must be true
select pg_has_role('authenticator', r, 'member') as can_switch
from unnest(array['anon','authenticated','service_role']) as r;

-- API roles still need schema USAGE
select has_schema_privilege('anon','public','usage') as public_usage,
       has_schema_privilege('anon','app_api','usage') as app_api_usage;

If step 1 fixes it, it is worth reporting the trigger sequence (Management-API migration touching function signatures/grants ? silent listener death ? NOTIFY becomes a no-op) as a Supabase issue: a reload channel that can die quietly turns every future migration into a potential landmine, and "restart PostgREST" should not require a ticket.

[solvionholdings]

One thing doesn't fit the "frozen schema cache" theory: PostgREST builds the OpenAPI output at /rest/v1/ from its schema cache. If that output lists your functions with the right signatures, PostgREST can see them, unless something in front of it is caching that response. Newly created functions and a new schema failing too also suggests a platform-side issue, so I'd keep pushing the ticket with those two facts and a timestamp.

A security note for when RPC works again. login(p_username, p_password, p_hwid) and admin_list_users() are callable with the publishable key once they resolve. Check what anon can execute:

select p.proname,
       p.prosecdef as security_definer,
       has_function_privilege('anon', p.oid, 'execute') as anon_can_execute
from pg_proc p
join pg_namespace n on n.oid = p.pronamespace
where n.nspname = 'public'
order by 1;

New functions get EXECUTE for PUBLIC by default, so anon usually ends up with it. For admin-only functions:

revoke execute on function public.admin_list_users() from public, anon;

Also check authenticated if it shouldn't have access either. Then put an admin check inside the function, or move it to a schema the Data API doesn't expose. A login RPC also has no brute-force protection built in, so it needs its own rate limiting.

[cekuu35]

The fact that the OpenAPI spec still lists every function while every RPC returns PGRST202 narrows this a lot, and it points at the matching layer rather than the cache itself: the schema cache has the functions (that is what the spec renders from), so something in how PostgREST resolves your call against those signatures fails for all of them. Three checks, in order — the first one is five seconds:

1. Parameter names, not positions, are what a JSON body matches on.

PostgREST maps a JSON object to a function overload by parameter name. If the JSON keys do not match the function's parameter names exactly, resolution fails with exactly this error — including for functions you are sure exist. p_username/p_password/p_hwid looks right, but the signature is the ground truth:

select p.proname,
       pg_get_function_identityarguments(p.oid) as signature,
       pg_get_functiondef(p.oid) like '%set search_path%' as has_set_clause,
       p.proowner::regrole as owner
from pg_proc p
join pg_namespace n on n.oid = p.pronamespace
where n.nspname = 'public'
order by p.proname;

Compare the signature output's parameter names with the JSON keys you send, character for character. Two things that produce this symptom silently: the function was defined with different parameter names than the client sends (a rename that never broke the spec, because the spec lists types and the caller keeps sending old keys), and multiple overloads with the same argument count — when two overloads both match by name, PostgREST cannot disambiguate and reports "no matches found in the schema cache" rather than "ambiguous", which reads as a cache bug.

2. Zero-argument functions failing too is the tell.

If select p.proname shows zero-argument functions failing, name-matching is not the (only) cause — nothing to match. The next check is whether the schema cache actually reloaded after whatever created them:

-- force a reload; if RPCs work immediately after, the watch was broken
notify pgrst, 'reload schema';

-- and check the watch mechanism itself is present
select evtname, evtevent, evtowner::regrole from pg_event_trigger where evtname like 'pgrst%';

notify pgrst, 'reload schema' is a reload, not a fix — but it diagnoses: if the RPCs work right after, then every statement that should have triggered a reload (the DDL that created or altered these functions) did not, which on a single-project basis usually means the DDL ran inside a transaction that was rolled back and re-run, or was executed by a role whose DDL the event trigger does not observe. Check postgres.log-adjacent evidence: select * from pg_stat_activity where query ilike '%create function%' will not show history, but the project's SQL editor history will.

3. What changed on 2026-10-22.

You wrote that the failure started that day. Before it, these functions presumably worked — so something in the pair (function set / project configuration) changed. The candidates worth diffing: functions created or replaced that day (a search_path added, a parameter renamed, a default added — each changes the signature PostgREST resolves), a project-level db-schemas or extra-search-path change (Dashboard → Settings → API), or a PostgREST restart on a config change (the version string you quoted, 14.5, is consistent with a recent project action). If anything in that window ran alter function ... set search_path on the affected functions, note that functions with a SET clause are exposed but their overload resolution includes the SET-parameter types — a SET on a parameter with a type from a non-exposed schema makes the overload unmatchable while still listed.

The practical sequence: run \df+ public.login (or the query above), compare parameter names to your JSON keys, then notify pgrst, 'reload schema' and retry one call. If the reload alone fixes it, the cause is on the DDL-watch side and it will recur on the next function you create until that is addressed. If it does not, the signature comparison will show you what the resolver sees. Paste the signature output for one failing function and the exact body you post, and the mismatch — if there is one — will be visible in one read.

One thing this is not: not the anon-key exposure question, and not RLS — RPC 404 happens before policies are consulted, which is why the tables still work while every function fails.