Fix: supabase-js JSONB containment bug breaks shared-project queries

Passing a JS array to supabase-js `.contains()` on a JSONB column sends Postgres array-literal syntax (`cs.{x,y}`), which Postgres rejects. The fix is one line: wrap the array in `JSON.stringify()` so supabase-js emits `cs.<jsonarray>` instead.

infrastructureworkflow

Maintained by Allen Morgan · verified on MikeWatch

shared_with is a JSONB column. supabase-js's .contains([userEmail]) generates a PostgREST cs.{email@example.com} filter, which PostgREST passes to Postgres as-is. Postgres reads it as an array literal, not a JSON array, and returns "invalid input syntax for type json". The result: every query that checks whether a project is shared with the current user silently 500'd.

The fix appears in three places: lib/access.ts:listAccessibleProjectIds, routes/projects.ts (list and getById lookups), and routes/tabular.ts (direct-share review lookup). In each case .contains("shared_with", [userEmail]) becomes .contains("shared_with", JSON.stringify([userEmail])).

Altien pairs the fix with two behavioral changes. Structured error logging replaces the previous pattern where the raw Postgres error message hit the response body with no backend trace. More significantly, the failure mode for the shared-projects query is downgraded from "fail the request" to "log and return an empty shared set." If the query fails for any reason - misconfiguration, transient error, anything - the user's own projects still come through. The owned-projects query remains fatal.

The bug exists in the upstream willchen96/mike codebase. The fix is self-contained and has no provider-boundary dependencies.

So what The most upstreamable change in this branch. Verify the upstream still has the bug (check `routes/projects.ts` for `.contains("shared_with", [userEmail])`), then the diff is a straightforward one-line fix with accompanying error-handling improvements. If you're running any deployment that uses shared projects, this is broken until patched.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

1 commit from Altien/mikeOssAzure, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
1c9e295b fix(jsonb): shared_with containment uses JSON-stringified arrays Allen Morgan 2026-05-08 ↗ GitHub
commit body
supabase-js's .contains([...]) on a JSONB column was emitting Postgres
array-literal syntax (cs.{x,y}), which Postgres rejects with "invalid
input syntax for type json". Passing a JSON-formatted string instead
produces cs.<jsonarray>, which PostgREST interprets as JSON containment
(@>). Affects:

  * lib/access.ts        - listAccessibleProjectIds
  * routes/projects.ts   - list + getById + share lookups
  * routes/tabular.ts    - direct-share review lookup

The fix is paired with structured logging on every shared_with query
(the previous shape silently 500'd with a raw Postgres message in the
response body and no backend trace) and downgrades the shared-projects
failure mode from "fail the whole request" to "log + return owned
projects only" so a transient shared-with failure can't lock a user
out of their own data.

Worth upstreaming as an independent bug-fix PR once the provider-
boundary refactors land.

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-196.md from inside the repo you want the changes in.

⬇ Download capture-thread-196.md