Non-200 status Responses do not expose message

[cryptoseneca]

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 returning responses from Edge Functions, Documentation suggests new Response('..', {status: 200}). This works fine as one can see the success message in the data var. When returning a Response with a non-200 status code, the message is not available to the client.

edge func:

    return new Response(
      JSON.stringify({ success: `all went through smoothly!` }),
      {
        status: 200, // 200 or 400
      },
    );

client:

    const { data, error } = await supabase.from('table').select('*').eq('id', id);

When it is a 200 response, data will display the message but when it is non-200 (eg 400), the error var does not show the message - it only returns a generic message:

FunctionsHttpError: Edge Function returned a non-2xx status code

To Reproduce

Explained above.

Expected behavior

error to contain whatever message is added to the Response object.

System information

• OS: macOS
• Version of supabase-js: "@supabase/supabase-js": "^2.20.0"
• Version of Node.js: v16.17.1

[bombillazo]

This simple, if the response .ok value is false (only true for values 200-299), the code throws a FunctionsHTTPError:

functions-js/src/FunctionsClient.ts

Lines 97 to 99 in af4113a

	if (!response.ok) {
	throw new FunctionsHttpError(response)
	}

This error is gobbling up the error thrown and returns a generic message:

functions-js/src/types.ts

Lines 38 to 42 in af4113a

	export class FunctionsHttpError extends FunctionsError {
	constructor(context: any) {
	super('Edge Function returned a non-2xx status code', 'FunctionsHttpError', context)
	}
	}

These custom function error classes are opinionated and override the expected error response of the edge function logic. However, the error returned has a context property that contains what you would expect to receive.

functions-js/src/FunctionsClient.ts

Lines 80 to 99 in af4113a

	const response = await this.fetch(`${this.url}/${functionName}`, {
	method: method || 'POST',
	// headers priority is (high to low):
	// 1. invoke-level headers
	// 2. client-level headers
	// 3. default Content-Type header
	headers: { ..._headers, ...this.headers, ...headers },
	body,
	}).catch((fetchError) => {
	throw new FunctionsFetchError(fetchError)
	})
	const isRelayError = response.headers.get('x-relay-error')
	if (isRelayError && isRelayError === 'true') {
	throw new FunctionsRelayError(response)
	}
	if (!response.ok) {
	throw new FunctionsHttpError(response)
	}

[0xpaperhead]

+1

[lavisht22]

+1

[bettysteger]

If anyone comes here and just want to show the error, this was my solution:
https://supabase.com/docs/guides/functions/quickstart#error-handling

import { FunctionsHttpError } from '@supabase/supabase-js'

const { data, error } = await supabase.functions.invoke('...')

if (error && error instanceof FunctionsHttpError) {
  const errorMessage = await error.context.json()
  console.log('Function returned an error', errorMessage)
}

[herringtown]

this was driving me crazy .. thank you @bettysteger for the fix. Can't believe this hasn't been patched..

[bombillazo]

@herringtown I've been using Supabase for more than 1 year, and they've been very absent and indifferent to their OS libraries. I've even contributed PRs to fix stuff and have waited for review for months. They seem more focused on patching only when it's supercritical or minimal effort. It's a frustrating state of affairs for such a product