nwhitehouse catches a silent data loss bug in chat history

User messages were quietly vanishing from the database - and nobody noticed because the screen looked fine.

chat-uiinfrastructure

nwhitehouse traced a bug where user-side chat messages were never actually being saved. The save call referenced a column that didn't exist in the database, so the database rejected every write - but the error was thrown away instead of surfaced. Live conversations looked normal because the browser was holding the history in memory; only on reload did the user's own messages disappear, leaving a one-sided transcript of just the AI's replies.

The fix itself is small. More interesting is what it exposes: errors from the storage layer were being silently swallowed across the codebase. Alongside the patch, nwhitehouse wired in proper error logging so the next time something like this breaks, it screams instead of hiding.

So what If you're evaluating a legal-AI tool, ask the vendor how they detect silent write failures - this is exactly the class of bug that erases discoverable history without anyone noticing.

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

SHA Subject Author Date

1271d07c [bug-001] Persist user messages - drop non-existent workflow column Nick Whitehouse 2026-05-03 ↗ GitHub

SHA	Subject	Author	Date
`1271d07c`	[bug-001] Persist user messages - drop non-existent workflow column	Nick Whitehouse	2026-05-03	↗ GitHub
commit body User messages were never being persisted to chat_messages. The insert referenced a `workflow` column that doesn't exist in the schema; Supabase silently rejected the entire insert with PGRST204 ("Could not find the 'workflow' column of 'chat_messages' in the schema cache"), and the result was unchecked. Affected both POST /chat and POST /projects/:id/chat. Effect: chats reloaded from the DB only showed assistant rows. Live chats appeared correct because the frontend keeps message history in memory. Fix: drop the `workflow` field from the insert in both routes, and surface any future insert errors via console.error so the next regression isn't silent. Same defensive logging added to the assistant-message insert. If per-message workflow attachment ever needs to survive a reload, add a column in a follow-up migration. Verified by direct insert against the prod schema: with workflow: PGRST204 (silently swallowed today) without workflow: OK Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

commit body

User messages were never being persisted to chat_messages. The insert
referenced a `workflow` column that doesn't exist in the schema; Supabase
silently rejected the entire insert with PGRST204 ("Could not find the
'workflow' column of 'chat_messages' in the schema cache"), and the result
was unchecked. Affected both POST /chat and POST /projects/:id/chat.

Effect: chats reloaded from the DB only showed assistant rows. Live chats
appeared correct because the frontend keeps message history in memory.

Fix: drop the `workflow` field from the insert in both routes, and surface
any future insert errors via console.error so the next regression isn't
silent. Same defensive logging added to the assistant-message insert.

If per-message workflow attachment ever needs to survive a reload, add a
column in a follow-up migration.

Verified by direct insert against the prod schema:
  with workflow:    PGRST204 (silently swallowed today)
  without workflow: OK

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

⬇ Download capture-thread-121.md