supabase / supabase / 28604219357

75%

push

github

fix: table-editor-negative-bigint-filter-precision (#47471)

Fixes: #47470

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Bug fix.

## What is the current behavior?

In the Table Editor, filtering a `bigint` (`int8`) column by a large
**negative** value
returns the wrong results (the matching row does not appear), while the
equivalent large
**positive** value works correctly.

`formatFilterValue` (`apps/studio/data/table-rows/utils.ts`) keeps
out-of-range bigint
filter values as strings so they reach Postgres without precision loss,
but it only guards
the upper end of the JS safe-integer range:

```ts
const numberValue = Number(filter.value)
// Supports BigInt filter values
if (Number.isNaN(numberValue) || numberValue > Number.MAX_SAFE_INTEGER) return filter.value
else return Number(filter.value)
```

`numberValue > Number.MAX_SAFE_INTEGER` is always `false` for negative
numbers, so large
negative bigints (e.g. the int8 minimum `-9223372036854775808`) fall
through and get rounded
by `Number()` (`Number('-9223372036854775808')` →
`-9223372036854776000`). The rounded value
is then sent to SQL, so the filter no longer matches the intended row.
The same helper feeds
the row count and "delete all matching" queries.

Steps to reproduce:

1. Create a table with a `bigint` column `id`.
2. Insert a row with `id = -9223372036854775808`.
3. In the Table Editor, filter `id = -9223372036854775808`.
4. The row is not returned. Filtering by `9223372036854775807` works as
expected.

## What is the new behavior?

Large negative bigints are now preserved as strings just like large
positive ones, so the
literal sent to Postgres matches what the user typed and the filter
returns the correct rows.

The fix guards the safe-integer range by magnitude:

```ts
if (Number.isNaN(numberValue) || Math.abs(numberValue) > Number.MAX_SAFE_INTEGER)
  return filter.valu... (continued)

1055 of 1461 branches covered (72.21%)

Branch coverage included in aggregate %.

1578 of 2147 relevant lines covered (73.5%)

248.87 hits per line