-
-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
shouldThrowOnError does not apply to functions.invoke() #20
Comments
invoke() call throws if shouldThrowOnError flag is set
This really surprised me as it seems I have to manually watch for the error argument in the function response and then throw the error if I want it to act like a traditional fetch api. I would love to have this incorporated and would be down to try and make a PR as well |
FYI - In the meantime I've made my own function for invoking supabase functions so that this behaves as expected:
|
I believe this behavior should be built in as well. Having to inspect the response every single time introduces many areas for errors. |
Bug report
Describe the bug
When
shouldThrowOnError
is set on supabaseClient, errors raised from functions.invoke() do not throw.Additional context
@supabase/functions uses the standard fetch API, which does not throw on HTTP status codes other than 2xx; in addition the wrapper does not return the HTTP status code in the response object which is always in the form
{ data, error }
.For instance, if the Edge Function was written to reject some unauthorized request by returning a
403 Forbidden
response, it is impossible to catch this condition.In other words, supabaseClient always returns
{ data, error: null }
, even when the HTTP status code indicates an error (unless of course if fetch itself threw in the first place).This forces the user to provide an additional 'httpError' key in the 'data' object, which feels convoluted and obliges to check errors at two different levels (in error and in data.httpError).
Proposed improvement
Modify the code of @supabase/functions:
1- Detect http status codes other than 2xx, and populate the error property in that case together with the status code, instead of populating the data property
2- Add an option to the invoke() function parameters to pass a shouldThrowOnError boolean flag. If set, throw rather than returning the { data, error } object
I can submit a PR if the above makes sense.
The text was updated successfully, but these errors were encountered: