supabase / supabase-flutter / 33188560437

89%

Build Type

push

github

Committed by web-flow

Commit Message

fix(realtime): parse Postgres array literals instead of splitting on commas (#1781)

## What

`toArray` in `supabase_realtime` decoded a Postgres array literal by
trying `json.decode` on the body and, when that threw, splitting the
string on every comma. Both paths carried a `TODO` and a `WARNING:
splitting on comma does not cover all edge cases`, and the edge cases
turn into wrong data in realtime payloads:

| Literal Postgres sends | Before | After |
| --- | --- | --- |
| `{"a,b",c}` | `['"a', ' b"', 'c']` (three elements) | `['a,b', 'c']` |
| `{NULL,a}` on `text[]` | `['NULL', 'a']` | `[null, 'a']` |
| `{"",a}` | `['""', 'a']` | `['', 'a']` |
| `{{1,2},{3,4}}` on `int4[]` | `[null, null, null, null]` | `[[1, 2],
[3, 4]]` |

A `text[]` column whose values contain commas is the common case here:
subscribers got extra elements with stray quote characters in them, and
nothing signalled that the value had been mangled.

This replaces both paths with a parser for the literal itself: comma
separated elements, optional double quotes where `\` escapes the next
character, whitespace around unquoted elements dropped, an unquoted
`NULL` as the null element (a quoted `"NULL"` stays the four character
string), and nested arrays keeping their shape. A literal that doesn't
parse now returns the raw string instead of data that looks structured
but isn't.

`{}`, `{1,2,3}` and quoted ranges like `{"[2021-01-01,2021-12-31)"}`
behave exactly as before — the existing tests cover those and are
unchanged.

## Note on parity with supabase-js

`realtime-js` still has the same `JSON.parse`-then-split logic
(`src/lib/transformers.ts`), including the same TODO and warning
comments, so after this change the Dart client parses these literals
where the JS client does not. I went with correctness here since the
current behaviour silently returns wrong values, but happy to align
differently if you'd rather keep the two in lockstep, and I can open the
matching issue on `realtime-js`... (continued)

Coverage Stats

66 of 66 new or added lines in 1 file covered. (100.0%)

1 existing line in 1 file now uncovered.

6098 of 6877 relevant lines covered (88.67%)

4.55 hits per line