Bug report

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

Describe the bug

I'm new to supabase so apologies if this is not a bug. When using _invokeWithStreamedResponse the supabaseClient on the backend is unable to assume the auth role of the user making the request. I believe this is because of the different URLSession being used, as described in the function documentation, but it wasn't clear if this is a known side affect.

Is there a recommended workaround when using this function? Should I pass the user_id in the function body and assume an admin level role in the backend, or is that an anti-pattern with supabase?

To Reproduce

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

1. Make a request with the regular invoke function
2. Observe that user level auth header is sent
3. Make the same request using _invokeWithStreamedResponse
4. Observe that user level auth header is not sent

Expected behavior

Get the same authorization scopes as using the regular invoke function

Screenshots

System information

version 2.24.1

Additional context

Add any other context about the problem here.