fix(tables): log row writes to the change log instead of locking the table definition row

[TheodoreSpeaks]

Summary

• Phase 2 of improvement(tables): read row counts and versions through an append-only change log #8653: the user_table_rows triggers append to user_table_row_changes instead of updating the table's user_table_definitions row, so a row write no longer locks shared per-table state. A commit stalled on synchronous replication no longer makes every other writer to that table queue behind it and fail at the 3 s lock_timeout
• Insert/delete statement triggers log one +n / -n row per table per statement — that row is both the row-count delta and the version bump, replacing the row-count triggers (0224) and the version insert/delete triggers (0240, dropped). The deferred update trigger (0390) keeps its column filter and per-transaction dedupe and logs a zero-delta row
• Delete and update triggers skip tables whose definition is already gone: deleting a table or workspace cascades into its rows after the definition row is deleted, and logging those would violate the log's foreign key
• Swap runs in one transaction, so no write is double-counted or missed mid-migration. Readers already add the unfolded tail (improvement(tables): read row counts and versions through an append-only change log #8653), so the deployed app reads the same values before and after the migration
• apply-dev-table-triggers.ts installs the same functions and reconciles stored + tail against real counts; stale comments about the trigger lock updated
• Requires improvement(tables): read row counts and versions through an append-only change log #8653 deployed to prod first (it is merged) and the fold cron running (infra improvement(chat): optimized chat performance & pass/email flow for chat #406)

Type of Change

• Bug fix

Testing

• New row-writes.integration.ts case: a second session holds the definition row FOR NO KEY UPDATE (what a commit stuck in SyncRep holds) while insert, batch insert, upsert, update by id, update by filter, delete by filter, and replace each run. All seven commit (56 ms total) and live count = COUNT(*). Against the pre-change triggers the first insert fails at the 3 s lock timeout
• The cascade-delete foreign-key bug was caught by the TTL suite's fixture cleanup before the guard was added
• Table suites + TTL cleanup on a migrated DB: 148 passed; push-provisioned: 117 passed (migration-only cases skip as before). rows_version and TTL helpers now read stored + tail
• bun run lint, check:audits, check:migrations origin/staging, block-registry check, docs-manifest:check, drizzle generate clean, 1,011 table unit tests; root bun run test green except one desktop terminal test that passes in isolation

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing (new tests pass the test-audit authoring gate)
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

🤖 Generated with Claude Code

https://claude.ai/code/session_01CJxC2fgucGVpT59RV5Z7xv

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs	Ready	Preview	Oct 8, 2026 10:03pm UTC

[cubic-dev-ai]

We detected this is a high-risk PR and are running a free ultrareview. An ultrareview is a deeper, multi-pass review that catches hard-to-find bugs a standard review can miss. We'll post the findings when it completes.

This PR appears to change a database schema or migrate data, where a missed bug can corrupt or lose records, so a deeper multi-pass review is worth running.

Want an ultrareview on every high-risk PR? Set up automated ultrareviews.

[greptile-apps]

Confidence Score: 5/5

[Critical impact] The PR appears safe to merge with the stated deployment prerequisites.

Summary

Row writes now append count changes and version bumps to user_table_row_changes instead of updating the shared definition row.

• Migration 0401 swaps the trigger functions together and removes the old insert/delete version triggers.
• The development script locks the change log before reconciling stored counts with real rows.
• The held-definition test now covers both insert-side and existing-row upserts.
• Both previous review concerns are addressed. No new actionable issues were found.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  W["Row write"] --> T["Row triggers"]
  T --> L["user_table_row_changes"]
  L --> F["Fold job"]
  F --> D["user_table_definitions"]
  L --> R["Read stored values plus pending changes"]
  D --> R

Loading

_{Reviews (3) · Last reviewed commit: "fix(tables): lock the change log before ..." · Reviewed by Greptile}

[cubic-dev-ai]

We detected this is a high-risk PR and ran a free ultrareview. An ultrareview is a deeper, multi-pass review that catches hard-to-find bugs a standard review can miss.

This PR appears to change a database schema or migrate data, where a missed bug can corrupt or lose records, so a deeper multi-pass review is worth running.

Want an ultrareview on every high-risk PR? Set up automated ultrareviews.

All reported issues were addressed across 9 files

<sub>Reply with feedback, questions, or to request a fix.

Turn on auto-fix | Re-trigger cubic</sub>

[TheodoreSpeaks]

@greptile review

[TheodoreSpeaks]

@greptile review