Lef-F fixes the bug that quietly broke shared projects

If you shared a project with a colleague and they couldn't open it, this is why.

workflow

Lef-F tracked down a defect in how Mike stores who a project is shared with. When the database used a flexible JSON column for that list, the request to load any project shared with you - rather than created by you - failed outright. The owner saw their work fine; everyone they'd shared with hit an error and got nothing.

The culprit was a mismatch in how the share list was formatted before being sent to the database. Lef-F aligned the two broken spots with a third that already did it correctly, so shared access works again. The note is blunt about who's exposed: if your fork stores the share list in this format and you haven't patched it yourself, sharing is silently broken for everyone but the creator.

So what Anyone running a Mike fork where teams share matters or projects should check whether this bug is silently locking colleagues out.

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