POST requests to Edge Function silently dropped (net::ERR_CONNECTION_RESET) — preflight succeeds, request never reaches the function

[geminie14]

Project ref: qcljtqizujwxmxqrogkg
Function: make-server-1aee76a8 (Hono on Deno)

POST requests carrying an Authorization: Bearer header fail in-browser with net::ERR_CONNECTION_RESET / net::ERR_CONNECTION_CLOSED. Affects multiple routes: /community/join, /community/data (GET), /education/progress, /education/bookmark, /community/thread/create.

The key symptom: the OPTIONS preflight to the exact same path succeeds cleanly (204, ~1ms, logged normally). The actual POST/GET that follows never appears in the function's own Logs or Invocations tab at all — no boot, no invocation record, nothing. It's being dropped somewhere between the browser and the function, before the function is ever invoked.

Reproduced identically across Chrome, Edge, and a clean mobile browser with zero extensions — so this isn't a client-side/CORS/cookie issue.

Already ruled out:

Function code — confirmed unrelated to a separate (real, now-fixed) bug where we were still reading the retired SUPABASE_ANON_KEY/SUPABASE_SERVICE_ROLE_KEY secret names instead of the new SUPABASE_PUBLISHABLE_KEYS/SUPABASE_SECRET_KEYS. Fixed and redeployed (confirmed via the function's "deployed X minutes ago" timestamp) — issue persisted identically afterward, and since the request never reaches the function, this fix couldn't have mattered either way.
KV store table (kv_store_1aee76a8) — confirmed exists in Table Editor, correct schema, valid data.
Free tier usage limits — 30 Edge Function invocations this billing period, nowhere near any cap.
Platform-wide outage — status.supabase.com shows Edge Functions Operational, no relevant open incidents.
Google OAuth redirect URI / client ID / secret — all confirmed to match (this was a separate issue earlier in the same project, now resolved, but the same evidence-gathering ruled it out as a factor here too).

Already opened a support ticket (SU-442129, High severity) but wanted to post here too in case someone's seen this pattern before — the "preflight succeeds, real request vanishes with zero function-side trace" combination feels like it points at something in the gateway/routing layer in front of the function rather than anything in our code.

Has anyone run into this? Any pointers on what else to check (or logs we could pull) would be hugely appreciated.

[k1ng-arthur]

Could it be a network/firewall issue where it treats options different to GET requests? if you use a vpn or different network do you still get the issue?

[geminie14]

Just tested on cellular data (LTE, no WiFi) instead of home network, same failure (net::ERR_CONNECTION_RESET client-side, "Could not join community" in-app). So it's not a network/firewall/VPN issue on my end, reproduced now across home WiFi, mobile data, three browsers (Chrome, Edge, mobile), and a completely clean device with zero extensions. Appreciate you thinking of that angle though!

[PARTH1s]

I’d try to isolate whether the reset is happening at the client/network edge before the Edge Function gateway.

Since the OPTIONS request reaches the function and succeeds, while the subsequent authenticated GET/POST never appears in Invocations, I’d compare the failing request outside the browser:

1. Run the same request with curl -v using the exact function URL and Authorization header.
2. Try the same curl request from a completely different network (mobile hotspot/VPN vs current ISP).
3. Compare IPv4 vs IPv6 resolution/connectivity if the hostname has both A and AAAA records.
4. Check whether there is any corporate/ISP proxy, WAF, DNS filter, or firewall inspecting/dropping requests containing Authorization: Bearer.
5. Compare a request without the Authorization header, then add only the header and retry.
6. If curl also gets connection reset/closed and there is still no function invocation, that would make the gateway/routing path much more likely than application code or CORS.

For example:

curl -v \
  -X POST \
  'https://<project-ref>.supabase.co/functions/v1/make-server-1aee76a8/community/join' \
  -H 'Authorization: Bearer <token>' \
  -H 'Content-Type: application/json' \
  --data '{}'

Also worth testing:

curl -4 -v ...
curl -6 -v ...

If -4 works but -6 resets, that would strongly point toward an IPv6/network path issue rather than the Edge Function itself.

Given that OPTIONS succeeds but the authenticated request disappears before invocation, I’d focus on identifying exactly where the TCP/TLS/HTTP connection is being terminated rather than changing the function/CORS code.

[geminie14]

Update, found it, and it wasn't Hono/routing at all.

Ran the curl test PARTH1s suggested with a real (not fake) access token, and got a clean 401 UNAUTHORIZED_ASYMMETRIC_JWT instead of a connection reset — that was the crack we needed.

Root cause: our project was migrated to Supabase's new asymmetric JWT signing keys at some point (part of the broader 2026 API key changes — same rollout that renamed SUPABASE_ANON_KEY/SUPABASE_SERVICE_ROLE_KEY to SUPABASE_PUBLISHABLE_KEYS/SUPABASE_SECRET_KEYS, which we'd already hit and fixed separately). Real user tokens are now signed with the new format, but there's a platform-level "Verify JWT" gate in front of every Edge Function, separate from and before Hono ever sees the request, that only understands the old legacy format. It was silently rejecting valid tokens before our code, or Hono's router, ever ran. That's exactly why nothing showed up in the function's own logs. It never got that far.

Fix: turned off "Enforce JWT Verification" in the function's Settings tab, since we already do our own supabase.auth.getUser() check in every route. /community/join and our education bookmark endpoint are confirmed working now.

One more route (/community/thread/create) is still failing the same way even after the fix, so I'm double-checking whether that's the same gate issue not fully applied yet, or a separate/unrelated bug on our end (possibly a route that doesn't actually exist server-side) — will update once confirmed, but wanted to close the loop on the main mystery since it's very likely to bite others hitting the same 2026 key migration.

Thanks again to you, the curl-outside-the-browser suggestion is what actually cracked this.