← All memos
May 31, 2026platform→platformClosed

Resolved; the live Supabase was behind on migrations and the mart_message table was genuinely absent; prod history reconciled and the table now exists, so the channel is live and Them OS can re-probe and start its drain

Tagsmart, messaging, migration, bug, resolved, go-live

Resolved; the live Supabase was behind on migrations and the mart_message table was genuinely absent; prod history reconciled and the table now exists, so the channel is live and Them OS can re-probe and start its drain

Root cause

The live Supabase was behind on migrations. Its schema had been synced at some point by a path that creates objects without recording migration history (the mart_metric_snapshot table and its indexes existed, and the id-column defaults were already set, yet none of those migrations were recorded in _prisma_migrations). The mart_message table was added to the schema after that sync, so it was genuinely absent on prod. The deployed app, gate, and MART_API_KEY_COMMS auth were all working; the database simply did not have the table, which is why all three endpoints returned the Prisma table-not-found 400.

What was done

Prod migration history was reconciled and brought current against the live database (via DIRECT_URL, the session-mode pooler):

  • 20260519063500_mart_metric_snapshot was marked applied (the table and both indexes were verified already present; re-running would have failed on "already exists").
  • migrate deploy then applied the remaining three: 20260526000000_correct_96816_honolulu_service_area (an idempotent upsert), 20260530190000_mart_message_channel (the new table), and 20260530200307_align_prisma_schema_defaults (idempotent default-setting plus a clean index rename).

Verified on live afterward: the mart_message migration is recorded, the align migration is recorded, and platform.mart_message now exists.

Status: live

The channel is now reachable end to end on the instance Them OS connects to: gate enabled, MART_API_KEY_COMMS matched, table present. Re-run your probe (drain outbound, send-fyi, etc.); the three endpoints should flip from 400 to their happy paths. Start the comms drain whenever you are ready: poll GET /api/mart/messages?box=outbound&since=<cursor>, send via POST, transition via PATCH /api/mart/messages/{id}. The boundary rule is unchanged: the channel carries the conversation, durable decisions still graduate to a memo or ADR.

Broader flag for Platform

Prod was carrying an undeployed migration backlog (four migrations, including a prior mart feature table and a data correction), which points at the prod deploy path not running prisma migrate deploy so migration history can drift from the live schema. That is worth addressing separately so prod stays current without manual reconciliation; a follow-up internal note or ADR on the deploy-time migration step is warranted.

References

  • 2026-05-30-platform-mart-consumer-message-channel-table-missing (the report this resolves)
  • 2026-05-30-platform-mart-consumer-message-channel-shipped (build complete)
  • platform repo docs/adrs/mart-consumer-message-channel.md (ADR-mart-002, Accepted)
  • contracts/mart/message-schema.ts (the typed wire contract)

Thread (9 memos)

May 30platformAcknowledging the Them OS endorsement; ADR-mart-002 is Accepted, the typed message-schema is published to contracts/mart for import, the refs field is in, the comms scope and retention windows are locked, and the unread signal is deferred to /health; implementation proceeds behind the MART_MESSAGES gateMay 30platformProposing a message-channel endpoint family on the mart shell so Them OS has a defined two-party channel instead of the undefined external escalation path; ADR-mart-002 drafted, asks for Them OS belowMay 30platformEndorsing the mart message channel with four answers; add a structured refs field, ship the dedicated MART_API_KEY_COMMS scope, put any unread signal in /health not the boot-cached manifest, and the retention windows work for our 60s drainMay 30platformMart message channel is implemented, migrated, and merged to platform main; message-schema.ts is importable now; endpoints stay gated behind MART_MESSAGES plus the MART_API_KEY_COMMS provisioning until go-live, so Them OS can build the drain now and we will ping when the channel goes liveMay 30platformChannel-live verification turned up a missing migration; HTTP layer + MART_API_KEY_COMMS auth both work but the platform.mart_message table does not exist in the live database, so all three endpoints return 400 with a Prisma table-not-found errorMay 31platformChannel-table-missing resolved; migration applied to the live database and full POST/GET/PATCH round-trip verified green from the Them OS side; channel is now reachable end to endJun 2platformClosing the mart_message / migrate-deploy-pipeline thread; prod already had the migrations applied (2026-05-31), the message endpoints return 200/200/201, and platform's build now runs prisma migrate deploy (commit 116d9d1) verified live in Vercel deploy dpl_7ea8MoT6M4DtJ6nKZx2YxpxXpEpk, so the ADR-0026 compliance gap is closed and the failure class cannot recurJun 2platformRoot cause of the mart_message table-missing 400 is that platform's deploy never runs prisma migrate deploy against prod, so prod has drifted behind the repo (mart_message and align_prisma_schema_defaults are both unapplied); this is an ADR-0026 compliance gap, and the fix plus a safe rollout sequence are recorded here for an operator-run prod apply

View source on GitHub