Lef-F catches a silent shared-projects bug

Anyone opening a project that a colleague had shared with them was hitting a server error - Lef-F traced it and pushed a fix worth pulling upstream.

workflow

While building a one-command self-hosted version of Mike, Lef-F hit a wall: any logged-in user trying to load their projects list got a server error instead of seeing what colleagues had shared with them. The root cause was a small mismatch in how Mike's backend was talking to its database - easy to miss in development, impossible to ignore on a fresh install.

The fix is tiny and isolated from the broader self-hosting work around it. Lef-F packaged it cleanly so the upstream maintainers can pick it up on its own, without inheriting any of the install plumbing it was discovered alongside.

So what Anyone running Mike for a team should check whether they're hitting this - shared workspaces are quietly broken until the fix lands upstream.

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 Lef-F/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date

653d0550 fix(backend): use JSON-array form of contains() for jsonb shared_with Lef 2026-05-05 ↗ GitHub

SHA	Subject	Author	Date
`653d0550`	fix(backend): use JSON-array form of contains() for jsonb shared_with	Lef	2026-05-05	↗ GitHub
commit body PostgrestFilterBuilder's .contains(column, value) serializes a JS array as PostgreSQL array literal '{a,b}', which is the right shape for text[] columns but invalid input for jsonb. Two of three call sites (projects.ts and access.ts) passed bare arrays, causing every GET /projects request to return 500 with 'invalid input syntax for type json' on vanilla Postgres+PostgREST. The third site (tabular.ts:107) already uses JSON.stringify([...]) - this commit makes the other two match. Tested by tracing the generated PostgREST URL: bare array produces 'cs.{smoke@test.local}' (4xx), JSON.stringify produces 'cs.["smoke@test.local"]' (200).

commit body

PostgrestFilterBuilder's .contains(column, value) serializes a JS
array as PostgreSQL array literal '{a,b}', which is the right shape
for text[] columns but invalid input for jsonb. Two of three call
sites (projects.ts and access.ts) passed bare arrays, causing every
GET /projects request to return 500 with 'invalid input syntax for
type json' on vanilla Postgres+PostgREST. The third site
(tabular.ts:107) already uses JSON.stringify([...]) - this commit
makes the other two match.

Tested by tracing the generated PostgREST URL: bare array produces
'cs.{smoke@test.local}' (4xx), JSON.stringify produces
'cs.["smoke@test.local"]' (200).

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-40.md from inside the repo you want the changes in.

⬇ Download capture-thread-40.md