Altien fixes a sharing bug that could lock users out of their own projects

A small query fix in Altien's fork stops shared-project lookups from silently failing - and from taking the rest of the page down with them.

infrastructureworkflow

When a user opened their project list, Mike was asking the database a question about who a project had been shared with. The way that question was being phrased didn't quite match what the database expected, so it returned an error - and the error wasn't being caught gracefully. The result: a raw database message in the response and, in the worst case, a user unable to see their own work.

Altien's fix does two things. It rewrites the query so the database understands it, and it changes what happens if a sharing lookup ever fails again - instead of breaking the whole page, the user still sees the projects they own. The author flags this as the cleanest candidate in the fork to push back to the upstream Mike project, since it's a pure bugfix with no fork-specific baggage.

So what Anyone running Mike in production should check whether their users are quietly hitting this - it's the kind of bug that looks like a flaky page until someone complains they've lost access to their files.

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

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.

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