Edge Function returns NOT_FOUND despite successful dashboard deployment

[arogundadesamuel07-oss]

Hello Supabase Support,

My project has an Edge Function named lgt-ai-chat that appears active in the dashboard. Its code deploys successfully, and the function previously returned a successful response when tested in the dashboard.

However, requests to:

https://zfbjondjbsxkhqaoasmk.supabase.co/functions/v1/lgt-ai-chat

return HTTP 404 with this response:

{"code":"NOT_FOUND","message":"Requested function was not found"}

The browser's OPTIONS preflight request also returns 404, preventing my frontend from calling the function. I have redeployed it from the dashboard, but the issue persists.

Please investigate whether the function metadata or deployed bundle is missing or inconsistent in the Edge Function runtime.

Thank you.

[kamilkaczmareksolutions]

{"code":"NOT_FOUND","message":"Requested function was not found"} comes from the Functions gateway before your code runs. that's also why the OPTIONS preflight is a 404: it isn't a CORS problem, so CORS headers in your function won't fix it

1. check the slug, not the display name: supabase functions list --project-ref <ref>. the URL must use the exact slug (case-sensitive), e.g. /functions/v1/lgt-ai-chat
2. make sure the frontend calls the same project ref you deployed to (env vars / createClient URL)
3. test without the browser: curl -i -X POST https://<ref>.supabase.co/functions/v1/<slug> -H "Authorization: Bearer <anon key>" -H "Content-Type: application/json" -d '{}'
4. redeploy from the CLI to rule out a dashboard-only issue: supabase functions deploy <slug> --project-ref <ref>

if the slug is listed and curl still returns NOT_FOUND, it points to a platform-side issue. open a support ticket with the project ref, slug and a failing request timestamp

[aniket-r2Dev2]

To build on the slug/project checks above, I would compare the previously successful dashboard invocation with one failing external request before redeploying again.

Supabase distinguishes Invocations (request/response information) from Logs (execution events and custom messages): https://supabase.com/docs/guides/functions/logging

For one request through each route, record:

• UTC timestamp and HTTP method.
• The project reference and exact function slug.
• Response status/body.
• Whether a corresponding invocation or execution log appears.

Keep credentials and request payloads out of anything shared here.

The important distinction is whether the dashboard test still succeeds now. A historical success proves the function ran at that time, but does not establish that the current public URL resolves to the same deployment.

If a current dashboard test succeeds while the external request returns NOT_FOUND, compare their target project and slug first. If they match, those paired timestamps give support a much stronger routing/deployment case to investigate.

If both now fail, include the current deployment status/version and the function-list output alongside the failing timestamp. A listed deployment alone does not prove the invocation path is healthy.

The [status-code documentation] associates 404 with a missing function or incorrect URL. An absent execution log is useful supporting evidence, but I would not treat that alone as proof that the handler never ran.

Could you confirm whether the dashboard invocation still succeeds, and share the redacted results of that comparison? I have not invoked your endpoint or inspected your project.

[ghozali25]

A 404 NOT_FOUND here almost always means the request never reached a deployed function — it's a routing/URL problem, not your function code. The key clue is in your own report: it works from the dashboard tester but not from your external call. The dashboard invokes the function within the project you're viewing; your external request goes wherever the URL points.

Work through this in order:

1. Check the project ref in your URL. It must be https://<project-ref>.supabase.co/functions/v1/<function-name>, where <project-ref> belongs to the project you deployed to. If you have more than one project, deploying "successfully" in project A's dashboard and then calling project B's URL produces exactly this symptom.

2. Check the function slug matches exactly. Dashboard → Edge Functions lists what is actually deployed. The slug is the folder name at deploy time and it is case-sensitive — a renamed folder or a small typo returns 404.

3. Rule out auth. A missing or invalid Authorization: Bearer <anon-key> header returns 401, and verify_jwt misconfigurations also surface as 401/403 — not 404. A 404 means the function doesn't exist at that URL.

4. Check Invocations, not just Logs. Dashboard → Edge Functions → your function → Invocations: look for an entry at the timestamp of your failing external call. No entry = the request never arrived, so it's URL/routing. An entry = the function ran, and the 404 came from inside your code (for example your own router returning NOT_FOUND).

If steps 1–4 all check out, redeploy with the CLI so the target project is explicit:

supabase link --project-ref <your-ref>
supabase functions list
supabase functions deploy <function-name>

If it still returns 404 after that, it's worth a support ticket — include the exact URL (with the key redacted), the timestamp of a failing call, and the fact that Invocations shows no entry for that timestamp.

[yos88da]

I sent a plain OPTIONS request (no body, no key) to a few paths on your project to see which function names the gateway knows:

• /functions/v1/lgt-ai-chat returns 404 NOT_FOUND
• a made-up name returns the exact same 404
• /functions/v1/lgt-ai returns 204

So Edge Functions routing on your project works: something deployed answers at lgt-ai, while nothing answers at lgt-ai-chat. A 404 from the gateway means no function exists at that exact name in the URL (status codes), which is also why the preflight fails before your CORS code can run.

Two ways to fix it:

1. If lgt-ai is your chat function, point your frontend at https://<your-ref>.supabase.co/functions/v1/lgt-ai, or call supabase.functions.invoke('lgt-ai').
2. If lgt-ai is a different function and you want the chat code at lgt-ai-chat, deploy it under that exact name: put it in supabase/functions/lgt-ai-chat, link the CLI to this project, and run supabase functions deploy lgt-ai-chat.

You can confirm the result in a terminal: curl -i -X OPTIONS https://<your-ref>.supabase.co/functions/v1/lgt-ai-chat should stop returning the 404 NOT_FOUND once the name in the URL matches a deployed function.

Still stuck? Our AI agent can fix it in your code and test your live app again. The first check is free. (I'm building VibeFix) https://vibe-fixer.com/?src=gh-52482