`throwOnError` with await returns nullable type

[dogukanakkaya]

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

.throwOnError should return non-nullable type because since in a case of error it will throw instead of returning an error object with null data object.

To Reproduce

See below code for example:

const { data, error } = await supabase.from('groups').insert({ name }).select('id').throwOnError().single()

In this example return type is nullabe { data: { id: string } } | null but it shouldn't because it'll throw on error.

In this case I have to do below to correct typing which doesn't make any sense to do extra if checks even though it's unnecessary:

const { data, error } = await supabase.from('groups').insert({ name }).select('id').throwOnError().single()

if (error) throw error

Expected behavior

If .throwOnError called return type must be { data: NonNullable<...>, error: null } or even without error object if possible.

Screenshots

System information

• OS: MacOS
• Version of supabase-js: 2.26.0
• Version of Node.js: 20.3.1
• Version of Typescript: 5.1.3

[wallpants]

Thank you for opening this issue. I was about to open an issue for this exact thing.

[rfreydi]

One workaround until it's resolved:

const get = async (id: string) => {
  const entity = await supabase.client.from('auth.users').select(`*`)
    .eq('id', id)
    .single()
    .throwOnError();

  return entity.data as NonNullable<typeof entity.data>;
}

[mmkal]

I opened a PR to support this: supabase/postgrest-js#494

I got impatient so I published it under @rebundled/postgrest-js. Here's how you can use it with @supabase/ssr:

npm install @rebundled/postgrest-js

import { CookieOptions, createServerClient } from '@supabase/ssr'
import { PostgrestClient } from '@rebundled/postgrest-js'
import { Database } from '~/db'

export const createClient = () => {
  const client = createServerClient<Database>(
    process.env.NEXT_PUBLIC_SUPABASE_URL,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY,
  )

  // @ts-expect-error `.rest` is protected
  const { rest } = client
  const wrapper = new PostgrestClient<Database>(rest.url, {
    fetch: rest.fetch,
    headers: rest.headers,
    schema: rest.schemaName,
  }).throwOnError()
  return Object.assign(wrapper, {
    rest,
    realtime: client.realtime,
    auth: client.auth,
  })
}

You can then use like:

import {createClient} from '..'

export default async () => {
  const client = createClient()

  const { data: user } = await client.from('users').select('*').single()

  console.log(`Hello ${user.username}`) // no need to check truthiness/ throw manually
}

If you need access to the non-throwing client, you can use createClient().rest. Note that if the PR is merged, it'll probably make sense to make a change in this repo too, so explicitly creating a new PostgrestClient wouldn't be necessary. But this seemed like a non-invasive way to let people try this out now.

[AlbertMarashi]

+1. this is kinda annoying tbh

[ThatGuySam]

Would changing the functionality of .throwOnError() break existing apps that depend on null to represent that the data wasn't found, for example with .single().throwOnError()?

One alternative could just be more chainable throw methods, such as:

throwOnEmpty()
throwOnFalsy()
throwOn( function(){} )

[AlbertMarashi]

I don't see why it would be backwards compatible to return non-nullable when returning an array of items. maybeSingle should stay nullable, and single should be non-nullable

[yatoogamii]

Any update on this feature ?

[TomasHubelbauer]

In addition to supabase/postgrest-js#494 there is also supabase/postgrest-js#364. That PR is also in limbo, linking here just because it is relevant to the issue at hand. Out of curiosity, does anyone see the issue with returning directly the value of data with throwOnError() instead of { data }? I can come up with one problem which is queries where you want to get count not data, but in my experience, going straight to .data is so common, it would be nice to see some wrapper/helper specifically for that and it makes even more sense when couple with throwOnError where you know either the data is good or the control flow took the exception path so you can't make a mistake by not handling the error.

[gurumaxi]

Any update on this feature?

[soedirgo]

Resolved in #1355