Open
Description
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
Originally, I was trying to figure out why passing in the error object to Sentry.captureException
would cause Sentry to treat the error object as a POJO, and not an Error
. The error response from postgrest-js was typed as PostgrestError
, which clearly extends Error
.
It seems that through a couple of semi-related changes (#502, #555, #562), the type PostgrestError
has started having more meaning than it signed up for.
As far as I can tell, this is the issue:
- If
throwOnError()
is used, then the error thrown by the client is a properPostgrestError
, which calls the super constructor, and would pass the checkerror instanceOf Error
. - If
throwOnError()
is NOT used, then the error has the same shape as aPostgrestError
, but the constructor is not used, which means it never calls the super constructor, and would not pass the checkerror instanceOfError
.
The obvious solution would be to either separate the "thrown" error type and the "not-thrown" error type.