René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Migration runner: chunked autocommit phases still run inside the mega-transaction","articleBody":"## Summary\n\n`packages/database/migration/20260625104904_canonicalize_language_codes/migration.ts`'s `run()` executes inside the migration runner's `prisma.$transaction(..., { timeout: 30min })` callback. Steps 3 and 4 of the migration use the `prisma` autocommit handle to commit chunked updates for `Response` and `ContactAttribute` (the two highest-volume tables), but this chunked work still runs *inside* the runner's outer transaction. As a result:\n\n- The chunked phases (steps 3–4) still consume the same 30-minute transaction budget as steps 1–2.\n- Locks acquired by steps 1–2 (on `Language`, `SurveyLanguage`, and `Survey` content rows) are held until `run()` returns, i.e. until steps 3–4 also finish.\n\n## Discussion / accepted trade-offs\n\nPer discussion on PR #8407 (review thread on `migration.ts` lines 29-32):\n\n- Response ingestion is not stalled by this: there's no `responseCount` column/trigger on `Survey`, and an insert's `KEY SHARE` lock on the `Survey` FK row is compatible with the content updates' `FOR NO KEY UPDATE` locks. What is blocked is survey *editing* during the migration — already true before this PR.\n- The timeout failure mode converges: committed chunks from steps 3–4 survive a transaction rollback/timeout, and retries re-walk mostly read-only ranges, so each retry attempt is progressively faster. Worst case is a crash-looping deploy that converges after a few attempts, not a stuck migration.\n\nGiven these mitigations, the PR author chose not to gate PR #8407 on this issue, but agreed it should be tracked as a follow-up.\n\n## Required changes\n\nEither:\n1. Add an opt-out in the migration runner (`packages/database/src/scripts/migration-runner.ts`) allowing a migration to declare that it should run partially or fully outside the mega-transaction, or\n2. Split this migration into two: a bounded-transaction migration for steps 1–2 (catalog + survey content), and a separate autocommit/chunked migration for steps 3–4 (`Response` + `ContactAttribute`).\n\n## Acceptance criteria\n\n- Chunked, high-volume update phases (Response/ContactAttribute canonicalization, and any future similar work) do not run inside the runner's long-lived transaction.\n- Locks from earlier bounded-transaction steps are released before chunked autocommit work begins.\n- Existing idempotency/retry behavior of the migration is preserved.\n\n## References\n\n- PR: https://github.com/formbricks/formbricks/pull/8407\n- Discussion: https://github.com/formbricks/formbricks/pull/8407#discussion_r3511286832\n\nRequested by: @xernobyl","author":{"url":"https://github.com/coderabbitai[bot]","@type":"Person","name":"coderabbitai[bot]"},"datePublished":"2026-07-02T09:27:17.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/8410/formbricks/issues/8410"}