`Count` will not return same value counted as in `data.length` when filtered by nested `!inner` criteria.

Bug report

I think I found a bug when counting !inner joined tables with foreign filters.

Describe the bug

When a table is filtered by properties of the same table, count and data.length will match (considering no limit and count to be ‘exact’). When a table is filtered by !inner properties of other tables, data.length returns correct number of results, but count still return the correct one considering there are no foreign filters.

To Reproduce

Given 2 tables, Users and Roles for instance. If I activate count and filter by a Correct filter of User_id but an Inexistent Incorrect role inner filter the count will return 1 but with no data in the array.

  const {data, error, count} = await supabase.from('users')
   .select('*, role:roles!inner(*)', {count: 'exact'})
   .eq('user_id', 123) // This is a matching correct user
   .eq('role.name', 'whatever') // This will never be true.
  data.length === 0 // true (This is correct since roles will never match here)
  count === 0 // false (This should be true, count should be 0)
  count === 1 // true (This should be false, but returns 1 because the filter by user still is valid)

Expected behavior

1. Given a no limited query, data.length and count should match in all the cases (when using {count: 'exact'}).
2. Filtering inner joined tables should also affect the count of the query.

System information

• OS: macOS
• Browser (if applies) node.js
• Version of supabase-js: 1.28.5
• Version of Node.js: 14.18.1

[Egnus]

The Support team managed to upgrade me to PostgREST 9 and now the test query returns the commented correct response in #4170. And of course, the count now matches the expected results for all the cases I had already a test case implemented.

Thanks and closing issue.

[Egnus]

Done, with support ticket 3838, and also, to add more info to the test I did.

I executed:

GET https://__.supabase.co/rest/v1/trips?id=is.anything

Despite that trips is not existent for me, the answer to this query should be (and was) similar (if not the same) than with <9.0 versions with this response:

{
    "message": "syntax error at or near \"'anything'\"",
    "code": "42601",
    "hint": null,
    "details": null
}

I hope you have all you need (together with the email) to check this issue deeper.