ParserError "Unexpected input: .sum()" when using aggregate functions with TypeScript

[stefan-girlich]

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 I use aggregate functions, the inferred TypeScript data type will always depict an error, requiring me to use casts to any.

To Reproduce

  const { data } = await supabase.from("things").select(`
    field.sum(),
    ...other_things(id, name, color)
  `);

The inferred type for data seen in my VS Code is:
ParserError<"Unexpected input: .sum(),\n ...other_things(id, name, color)\n ">[] | null

Inference works fine when not using aggregate functions.
Re-generating TS types via supabase gen types typescript does not fix the issue.

Expected behavior

Types should be inferred correctly without an error.

System information

• OS: MacOS
• Version of supabase-js: 2.39.7
• Version of Node.js: 21.6.2

[encima]

Moving this issue to Postgrest-js repo. Issue is similar to #447 which was fixed recently

[stefan-girlich]

A brief update after upgrading supabase-js from 2.39.7 to 2.42.0:

Error in TypeScript type is now as following for the same original code:

const data: SelectQueryError<"Referencing missing column `sum`">[] | null

Using .count() instead of .sum() works as expected, but all other functions (.min(), .max(), .avg()) (src) still produce the error above.

@bnjmnt4n I just had a look into your fix for the similar issue with .count() (diff). Do you think it's sufficient to add sum, min, max, and avg in the same manner? Maybe there's also a way to reference the type AggregateFunctions (src)
Update: I think I found a way; looking into it.

[stefan-girlich]

@bnjmnt4n I added test cases which currently fail at compile-time.

[bnjmnt4n]

@stefan-girlich thanks for providing the examples; I'm really busy now so I can probably look at them next week only.

[stefan-girlich]

In case it helps anyone, here's a generic way to override the faulty type:

import fail from '@/utils/fail'
import { createClient } from '@/utils/supabase/server'

type FixSupabaseAggregateType<
  T extends readonly any[] | null,
  K extends keyof R,
  R extends Record<K, any>,
> = Array<Omit<NonNullable<T>[number], K> & R>

export const fetchSomeData = async () => {
  const supabase = createClient()
  const { data, error } = await supabase
    .from('some_table')
    .select(
      `
        some_prop,
        other_table(aggregated_prop:nested_prop.sum())
    `
    )

  if (error) fail(error)

  type Result = FixSupabaseAggregateType<
    typeof data,
    'other_table',
    {
      other_table: { aggregated_prop: number }
    }
  >

  return data as unknown as Result
}

@bnjmnt4n Would you know if a fix is scheduled already? Thanks!

[stefan-girlich]

@bnjmnt4n Would you know more? I can look into a solution/PR myself, but I'd be happy about some guidance concerning how to tackle this.

[sanjaybaskaran01]

Is this resolved? Facing the same issue here.

[veloware]

@sanjaybaskaran01 dont think it has been resolved, im also seeing the same when trying to use sum()

[avallete]

The fix has been released in supabase-js v2.46.0. I'm closing this issue, but feel free to reopen if you encounter any further errors.

[cohlar]

Hi @avallete,

Thanks for the update! I was excited to upgrade to 2.46.0, but it seems to be causing another issue: in the below code, the type inferred to data is string[].

const { data, error } = await supabase
          .schema('not_public')
          .from('my_table')
          .select('seller, ...sellers(code)')
          .match({ region });
if (error) throw error;

The inferred data type is correct either:

• when I remove , ...sellers(code)
• or when I downgrade back to 2.45.5

I'm writing this here because I have a feeling this issue is related to the fix of aggregate functions (if not, happy to create a new issue for this).

Thanks

[avallete]

Hey @cohlar do you think you could submit a request trough the supabase support, or if it isn't sensitive provide those infos for debugging:

1. The supbase.ts containing the Database types generations for your database
2. The exact query that is causing issue (I guess my_table is a replacement).

That way we can reproduce on our end and get this fixed.

[cohlar]

I created a case with supabase support ✅
Support Ticket ID: 15885286048

[cohlar]

Hi @avallete,

Thanks for the update! I was excited to upgrade to 2.46.0, but it seems to be causing another issue: in the below code, the type inferred to data is string[].

const { data, error } = await supabase
          .schema('not_public')
          .from('my_table')
          .select('seller, ...sellers(code)')
          .match({ region });
if (error) throw error;

The inferred data type is correct either:

• when I remove , ...sellers(code)
• or when I downgrade back to 2.45.5

I'm writing this here because I have a feeling this issue is related to the fix of aggregate functions (if not, happy to create a new issue for this).

Thanks

This now seems fixed on version 2.46.1 👍
Thank you!

[we-ink]

Still not working in 2.46.1 to me :/

[avallete]

Still not working in 2.46.1 to me :/

Hey @we-ink

Sadly the fixes did some unexpected breaking changes on some codebases. That's the reason why we reverted in 2.46.1 and we are currently considering it as a breaking change and releasing it following the release candidate procedure to let people the time to migrate. Please try the 2.46.2-rc.3 as recommended here: https://github.com/orgs/supabase/discussions/30324

And if you have any issues, please let us know by following the recommended procedure so we can debug and fix it 👍