fix: decouple validation and constraint adding for db

Without the not valid, the migration tries to create the constraint and validate it at the same time which can lock the entire table.
We decouple the validation and the constraint creation to avoid transaction timeouts

Author: nams1570

AGENTS.md

@@ -98,6 +98,7 @@ To see all development ports, refer to the index.html of `apps/dev-launchpad/pub
 - Fail early, fail loud. Fail fast with an error instead of silently continuing.
 - Do NOT use `as`/`any`/type casts or anything else like that to bypass the type system unless you specifically asked the user about it. Most of the time a place where you would use type casts is not one where you actually need them. Avoid wherever possible.
 - When writing database migration files, assume that we have >1,000,000 rows in every table (unless otherwise specified). This means you may have to use CONDITIONALLY_REPEAT_MIGRATION_SENTINEL to avoid running the migration and things like concurrent index builds; see the existing migrations for examples.
+- Each migration file runs in its own transaction with a relatively short timeout. Split long-running operations into separate migration files to avoid timeouts. For example, when adding CHECK constraints, use `NOT VALID` in one migration, then `VALIDATE CONSTRAINT` in a separate migration file.
 - **When building frontend code, always carefully deal with loading and error states.** Be very explicit with these; some components make this easy, eg. the button onClick already takes an async callback for loading state, but make sure this is done everywhere, and make sure errors are NEVER just silently swallowed.
 
 ### Code-related

apps/backend/prisma/migrations/20260210000000_deferred_email_retry/migration.sql

@@ -9,17 +9,19 @@ ALTER TABLE "EmailOutbox"
 
 -- Constraint: nextSendRetryAt can only be set after at least one failed attempt
 -- (if sendRetries is 0, no attempt has failed, so there's nothing to retry)
+-- Use NOT VALID to avoid holding ACCESS EXCLUSIVE lock during full-table validation.
+-- Validation happens in a separate migration to avoid transaction timeout.
 ALTER TABLE "EmailOutbox"
   ADD CONSTRAINT "EmailOutbox_nextSendRetryAt_requires_failure"
-  CHECK ("nextSendRetryAt" IS NULL OR "sendRetries" > 0);
+  CHECK ("nextSendRetryAt" IS NULL OR "sendRetries" > 0) NOT VALID;
 
 -- Constraint: sendAttemptErrors can only be set after at least one failed attempt
 ALTER TABLE "EmailOutbox"
   ADD CONSTRAINT "EmailOutbox_sendAttemptErrors_requires_failure"
-  CHECK ("sendAttemptErrors" IS NULL OR "sendRetries" > 0);
+  CHECK ("sendAttemptErrors" IS NULL OR "sendRetries" > 0) NOT VALID;
 
 -- Constraint: nextSendRetryAt must be null when email has finished sending
 -- (if finishedSendingAt is set, there's nothing more to retry)
 ALTER TABLE "EmailOutbox"
   ADD CONSTRAINT "EmailOutbox_no_retry_after_finished"
-  CHECK ("finishedSendingAt" IS NULL OR "nextSendRetryAt" IS NULL);
+  CHECK ("finishedSendingAt" IS NULL OR "nextSendRetryAt" IS NULL) NOT VALID;

apps/backend/prisma/migrations/20260210000001_deferred_email_retry_validate/migration.sql

@@ -0,0 +1,7 @@
+-- Validate the deferred retry constraints added in the previous migration.
+-- This runs in a separate transaction to avoid timeout, and only takes
+-- SHARE UPDATE EXCLUSIVE lock (allows concurrent reads/writes).
+
+ALTER TABLE "EmailOutbox" VALIDATE CONSTRAINT "EmailOutbox_nextSendRetryAt_requires_failure";
+ALTER TABLE "EmailOutbox" VALIDATE CONSTRAINT "EmailOutbox_sendAttemptErrors_requires_failure";
+ALTER TABLE "EmailOutbox" VALIDATE CONSTRAINT "EmailOutbox_no_retry_after_finished";