supabase / supabase-flutter / 36114631192

94%

push

github

fix(postgrest): keep a client-level Prefer header on writes (#1886)

## What

`insert()`, `update()` and `delete()` dropped the `Prefer` key from the
request headers, and `upsert()` overwrote it, so a `Prefer` set on the
client never reached a write. Every site that contributes a preference
now merges into the header by key.

## Why

A preference set once on the client is sent on reads and on RPC, but not
on writes:

```dart
final postgrest = PostgrestClient(url, headers: {'Prefer': 'tx=rollback'});

await postgrest.from('users').select();                 // Prefer: tx=rollback
await postgrest.rpc('f');                               // Prefer: tx=rollback
await postgrest.from('users').insert({'a': 1});         // Prefer absent
await postgrest.from('users').update({'a': 1}).eq(...); // Prefer absent
await postgrest.from('users').delete().eq(...);         // Prefer absent
await postgrest.from('users').upsert({'id': 1});        // Prefer: resolution=merge-duplicates
```

`tx=rollback` is the clearest case, because the writes are exactly the
requests the caller wanted rolled back, but the same applies to
`timezone=`, `handling=` and `max-affected=`.

The removal dates from the fix for the malformed `Prefer:
,return=representation` header. The empty seed was the actual cause of
that, and it is handled at every append site, so the key no longer has
to be deleted to keep the header clean. The twelve existing tests that
assert a clean or absent `Prefer` still pass untouched.

## Merging by key

PostgREST uses the first occurrence when a preference appears twice
(`ApiRequest/Preferences.hs`: `fromHeaders True [("Prefer", "tx=commit,
tx=rollback")]` gives `Just Commit`), so keeping the client's header is
only safe if the call's own preferences replace the ones they conflict
with. Appending alone would let the client's value win.

`maxAffected()` is the case that matters, because it is the guard on a
destructive write. It previously started from an empty header ... (continued)

28 of 29 new or added lines in 3 files covered. (96.55%)

8697 of 9543 relevant lines covered (91.13%)

4.92 hits per line