`maybeSingle()` Spams API Logs with `406` Errors

[caseycrogers]

Describe the bug
When using maybeSingle(), if no rows match the query the client properly produces a null value. However, from looking at the API logs, the server throws a 406 Not Acceptable error. Presumably the client is telling the server this is a single() and simply catching the error on no data.

This sounds like intended behavior so I'm not sure whether to call this a bug report or a feature request, but either way I'd really like maybeSingle not to pollute our error logs with 406's because it makes it much harder to figure out what our true error rate is and especially makes it hard to ensure that there are no legitimate 406 errors (ie a single() request finding no data).

To Reproduce
Steps to reproduce the behavior:

1. Create an empty table named test_foo with arbitrary columns
2. Run the following query from a client:

await supabase
  .from('test_foo')
  .select()
  .maybeSingle();

3. Query the API error logs for the relevant request:

        select
          t.timestamp::datetime as timestamp,
          t,
          response
        FROM edge_logs t
          cross join unnest(metadata) as m
          cross join unnest(m.response) as response
          cross join unnest(m.request) as request
          cross join unnest(request.headers) as headers
        WHERE t.event_message like '%test_foo%'

4. See that the request(s) produces 406 errors:

Expected behavior

maybeSingle() triggers a 200 OK or a 204 NO CONTENT or some other non-error HTTP response when no rows match the query.

Generally, I'd like it if the client never relies on the server returning an error status code for intended behavior. I'd like to be able to look at the API logs and know that every error (barring maybe retries and some other minor edge cases) represents a potential user-facing problem.

Version (please complete the following information):

├── supabase_flutter 1.10.0
│   ├── supabase 1.9.0
│   │   ├── functions_client 1.3.0
│   │   ├── gotrue 1.8.0
│   │   ├── postgrest 1.3.0
│   │   ├── realtime_client 1.1.0
│   │   ├── storage_client 1.4.0

Additional context

This problem scared the heck out of me when we launched because our API logs have a way-too-high ~1% error rate:

On inspection, over 50% of our 400+ responses are 406's. It took me several hours of panicked debugging to identify the maybeSingle() issue. I'm still not sure if all of our 406's are false alarms-some may still be legitimate users-facing issues. This also distracted me from inspecting our second largest group of errors (500's) which turned out to contain some legitimate bugs (poorly optimized queries timing out) massively hurting our user expierence.

I reached out to Supabase email support about this issue and they were not very helpful. I repeatedly asked what the 406's meant and if they were a problem or just expected behavior when using maybeSingle() and I repeatedly got unrelated answers.

[dshukertjr]

I will transfer this request to postgrest-js ot discuss it with the rest of the team.

[soedirgo]

@dshukertjr this is partially fixed in https://github.com/supabase/postgrest-js/pull/424/files - I don't remember what the edge case was though.

[dshukertjr]

@soedirgo Ah, nice! Thanks for the info! Bringing the issue back to supabase-flutter repo

[caseycrogers]

Sounds like the Flutter client just needs to be updated to bring it back up to parity with the JS client?