supabase / supabase / 42279400888

87%

push

github

fix(studio): prevent column comment data loss from sensitivity marker (#53051)

## What

Studio stores a column's "sensitive data" flag in-band by adding
`[SENSITIVE]` to the column's comment. The encode/decode helpers matched
the marker **anywhere** in the string, which caused two problems:

* A comment that merely *contains* `[SENSITIVE]` (e.g. `Fields marked
[SENSITIVE] are PII`) was wrongly treated as sensitive.
* The marker was stripped from the **middle** of the user's text on save
- even when the sensitivity toggle was off - silently corrupting
user-authored content.

Discussion: https://github.com/orgs/supabase/discussions/52699

## Changes

Following the direction in the discussion:

1. **One shared helper** - the marker logic was duplicated in three
places (`ColumnEditor.utils.ts`, `state/table-editor-table.tsx`, and the
toggle in `TableEditor/Column.tsx`), each slightly different. These are
consolidated into a single `lib/sensitive-column-comment.ts` with
`isSensitiveComment` / `encodeSensitiveComment` /
`decodeSensitiveComment`.
2. **Prefix-anchored detection and removal** - the marker is only
matched and stripped when it's an exact leading prefix (plus at most one
following space), so a mid-string `[SENSITIVE]` is preserved verbatim.
3. **Standardized the marker position** - `Column.tsx`'s toggle
previously appended the marker to the *end* of the comment, while the
column editor prepended it. The toggle now writes the canonical prefix,
so detection is consistent across all paths.
4. **Backward compatibility** - to avoid losing the flag on columns that
were saved with a *trailing* marker (the old toggle behavior),
`decodeSensitiveComment` also recognizes and strips an existing trailing
marker. Re-saving such a column migrates it to the prefix form.

## Example

```ts
// Before
encodeSensitiveComment('a [SENSITIVE] b', false) // -> 'a  b'  (data loss)

// After
encodeSensitiveComment('a [SENSITIVE] b', false) // -> 'a [SENSITIVE] b'  (prese... (continued)

2071 of 2439 branches covered (84.91%)

Branch coverage included in aggregate %.

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

2864 of 3223 relevant lines covered (88.86%)

200.37 hits per line