Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

When using supabase functions serve to serve all functions simultaneously, the pre-flight ‘OPTIONS’ request initiated by a browser agent fails. The server returns Status Code 408 - Request timeout with a message body of {"msg":"Request could not be processed by the server because it timed out or an error was thrown."}

The bug is triggered by the fact that the OPTIONS body is empty

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Use code snippet at https://supabase.com/docs/guides/functions/cors#recommended-setup to setup CORS headers in the serve function
2. Send OPTIONS request to edge function

Expected behavior

The server should return 200 with the CORS headers set appropriately.

Screenshots

System information

• OS: macOS
• Browser (if applies) : chrome. Also tested outside browser (Postman)
• Version of supabase-js: 2.20.0
• Version of Node.js: not relevant

Additional context

1. If serving the function individually via supabase functions serve <function-name>, the bug does not happen. It only happens when serving all functions simultaneously via supabase functions serve

2. If calling the function with the POST method directly, the bug does not happen.

3. Inserting console.log() statements everywhere in the edge function code shows that the script reaches the point where it has to send the response to the OPTIONS request, then crashes silently.

4. If you put some dummy data into the body of the OPTIONS request, the bug does not happen:

Unfortunately a browser-generated pre-flight request always has an empty body

To me it looks like when I call return new Response('ok', { headers: corsHeaders }) inside the edge function, this triggers the bug because probably the server-side is still waiting for the client to send its body and it does not want to reply with the Response before it can close the incoming connection - but I may be mistaken on my interpretation.

In conclusion, it looks like there may be some code inside edge-runtime that tries to enforce a non-empty body on an OPTIONS request ?