promptly3518 fixes the bug that broke shared projects

A database typing mismatch was quietly throwing errors whenever someone tried to load a project that had been shared with them.

infrastructureknowledge-management

Project sharing on this fork had a hidden fault: the query that checks who a project is shared with was sending data in a format the database refused to accept, so the request failed outright. promptly3518 traced it by first widening the error logging to capture exactly what the database was complaining about, then landed a small fix that reformats the lookup so the database accepts it.

The interesting part is that this is a known trap with Supabase - a popular hosted-database service - when a column stores data as flexible JSON rather than a plain list. Any team running a similar setup could be hitting the same silent failure without realising it. promptly3518 flags it as worth borrowing if your own sharing or access checks lean on the same pattern.

So what Anyone running a Supabase-backed fork with shared-access features should check whether the same mismatch is silently breaking their collaboration flows.

View this fork on GitHub →

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

Commits in this thread

2 commits from promptly3518/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`0e38936a`	Log full Supabase error context for GET /projects	promptly3518	2026-05-03	↗ GitHub
commit body Diagnostic for the 'invalid input syntax for type json' failure on project listing. The previous handler dropped error.code, .details, and .hint, leaving the frontend with just the bare message. Now the 500 response includes the full PostgREST error fields and Render logs get a JSON-stringified copy. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`f5ba5e8b`	Fix supabase-js .contains() JSONB serialization for projects.shared_with	promptly3518	2026-05-03	↗ GitHub
commit body supabase-js's .contains(column, value) generates PostgreSQL array literal syntax ({val1,val2}) when given a JS array. PostgREST then tries to parse this as JSON for a JSONB column and fails with 'invalid input syntax for type json'. Passing JSON.stringify([...]) forces it through the string-passthrough branch, producing valid JSON array syntax (["val1","val2"]) that PostgREST parses correctly. routes/tabular.ts already had the JSON.stringify form. Propagating the same pattern to the two remaining call sites. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

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

⬇ Download capture-thread-80.md