docker/server/entrypoint.sh (1)

77-98: Unresolved: path quoting and word-splitting risks remain.

The past review flagged two outstanding issues in this section that still need attention:

1. Line 97: find $WORK_DIR/apps is unquoted. Should be find "$WORK_DIR/apps" to safely handle paths with spaces.
2. Line 77: for sentinel in $unhandled_sentinels; do risks word-splitting if $unhandled_sentinels contains newlines or whitespace. Although sentinels match [A-Z_], the pattern is fragile. Consider a newline-safe loop:

-for sentinel in $unhandled_sentinels; do
+while IFS= read -r sentinel; do
+  [ -z "$sentinel" ] && continue

And update the done:

-done
+done <<EOF
+$unhandled_sentinels
+EOF

.github/workflows/docker-server-build-run.yaml (1)

35-76: Health-check hardening looks good; this addresses prior feedback.
You’re now (1) checking backend via /health, and (2) guarding against curl failures + empty status codes + quoting vars—matching the earlier review concerns.

apps/e2e/tests/backend/endpoints/api/v1/emails/email-queue.test.ts (2)

101-101: Fixed sleep assertions can yield false positives.

These tests use fixed wait() delays followed by "no messages" assertions. This pattern cannot distinguish between "email correctly skipped" and "processor never ran," making tests both flaky and prone to false positives.

Consider driving the processor explicitly or asserting against outbox status via the delivery APIs to confirm skip logic.

Also applies to: 166-166, 228-228, 301-301

Also applies to: 166-166, 228-228, 301-301

---

331-333: Placeholder snapshot must be replaced.

The snapshot placeholder "todo" needs to be replaced with the actual expected response body after running the test.

apps/backend/src/lib/email-queue-step.tsx (2)

224-231: Verify themeProps is accepted by rendering function.

The buildRenderRequest includes themeProps.projectLogos in the input object. Past review flagged that renderEmailsForTenancyBatched may not accept this field in its type signature.

Verify that the rendering function accepts themeProps in the input:

#!/bin/bash
# Check the RenderEmailRequestForTenancy type definition
rg -nP --type=ts -A10 'type\s+RenderEmailRequestForTenancy|interface\s+RenderEmailRequestForTenancy' apps/backend/src/lib/email-rendering.tsx

---

79-94: Missing automatic recovery for emails stuck in sending.

logEmailsStuckInSending only logs emails stuck in the sending state, while retryEmailsStuckInRendering (lines 59-77) actively resets stuck rendering jobs. This asymmetry means emails that crash during sending remain stuck indefinitely with startedSendingAt set but finishedSendingAt null, requiring manual intervention.

Consider adding automatic recovery for stuck sending jobs similar to rendering.

apps/backend/prisma/schema.prisma (1)

726-729: Verify bidirectional constraints are enforced in migration.

The comments document bidirectional constraints for emailDraftId and emailProgrammaticCallTemplateId:

• emailDraftId: "must be set if and only if createdWith is DRAFT"
• emailProgrammaticCallTemplateId: "Must be NOT set if createdWith is NOT PROGRAMMATIC_CALL"

Past review noted the migration may only enforce one direction of these constraints.

Verify the migration includes both directions of the constraint:

#!/bin/bash
# Check if both directions of emailDraftId constraint exist
rg -nP 'email_draft.*CHECK|EmailOutbox_email_draft' apps/backend/prisma/migrations/20251020180000_email_outbox/migration.sql

apps/backend/src/app/api/latest/internal/failed-emails-digest/crud.tsx (1)

67-68: Arrays accumulate duplicates from SQL join.

The SQL query produces a row per failed email per team member. Both emails (line 67) and tenantOwnerEmails (line 68) accumulate duplicate entries. The TODO comment acknowledges this but the issue remains unresolved.

Consider deduplicating before the loop or using a Map/Set to track unique entries.

.github/workflows/docker-server-build-run.yaml (1)

22-24: Avoid postgres:latest in CI; pin and clean up containers.
Using postgres:latest can break unpredictably. Pin to a major/minor (or at least major) version aligned with prod/dev (e.g. postgres:16). Also consider cleaning up the db container (and stackframe-server) at the end (or via trap) to reduce flakiness on runners that reuse Docker state.

apps/backend/src/lib/emails.tsx (1)

62-62: Remove unnecessary non-null assertion.

serializeRecipient(recipient)! uses a non-null assertion, but the function always returns Json (never null). The assertion is unnecessary.

Apply this diff:

-      to: serializeRecipient(recipient)!,
+      to: serializeRecipient(recipient),

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-04T18:03:49.984Z
Learning: Applies to **/*.{ts,tsx} : Always add new E2E tests when changing the API or SDK interface

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-04T18:03:49.984Z
Learning: Applies to apps/e2e/**/*.{ts,tsx} : Always add new E2E tests when changing API or SDK interface; err on the side of creating too many tests due to the critical nature of the industry

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-04T18:03:49.984Z
Learning: Run pnpm install to install dependencies, pnpm test run for testing with Vitest, pnpm lint for linting (use --fix flag to auto-fix), pnpm typecheck for type checking

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-04T18:03:49.984Z
Learning: Applies to **/*.test.{ts,tsx} : Prefer .toMatchInlineSnapshot over other selectors in tests when possible; check snapshot-serializer.ts for formatting details

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-04T18:03:49.984Z
Learning: Applies to packages/stack-shared/src/config/schema.ts : Whenever making backwards-incompatible changes to the config schema, update the migration functions in packages/stack-shared/src/config/schema.ts

apps/backend/src/auto-migrations/index.tsx (1)

104-196: Avoid sleeping while holding the advisory xact lock (and a DB connection)

await wait(500) runs inside the Prisma transaction, so it holds pg_advisory_xact_lock(...) and the transaction connection for the extra 500ms, which can amplify contention/timeouts when multiple workers race migrations. Prefer committing first, then sleeping before the next retry.

       await options.prismaClient.$transaction(async (tx) => {
+        let requestedRepeatDelayMs: number | null = null;
         log(`  |> Preparing...`);
         await tx.$executeRaw`
           SELECT pg_advisory_xact_lock(${MIGRATION_LOCK_ID});
         `;
@@
                 if (res[0].should_repeat_migration) {
                   log(`  |> Migration ${migration.migrationName} requested to be repeated. This is normal and *not* indicative of a problem.`);
-                  await wait(500);  // give the database a chance to catch up with everything else that's happening
+                  requestedRepeatDelayMs = 500; // delay after commit to avoid holding locks/connections
                   // Commit the transaction and continue re-running the migration
                   return;
                 }
@@
         newlyAppliedMigrationNames.push(migration.migrationName);
         shouldRepeat = false;
-      }, {
+        if (requestedRepeatDelayMs != null) {
+          // keep shouldRepeat=true, but sleep outside of the transaction
+        }
+      }, {
         timeout: 80_000,
         maxWait: 30_000,
       });
+      // If we returned early to repeat, wait here after commit/connection release.
+      if (shouldRepeat) {
+        await wait(500);
+      }
     }
   }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-04T18:03:49.984Z
Learning: Applies to packages/stack-shared/src/config/schema.ts : Whenever making backwards-incompatible changes to the config schema, update the migration functions in packages/stack-shared/src/config/schema.ts

apps/backend/prisma/migrations/20251212183000_migrate_sent_email/migration.sql (1)

4-15: Optional: make batching deterministic to reduce long-tail/dup work
Consider adding an ORDER BY se."id" (or createdAt/id) in to_migrate to avoid non-deterministic LIMIT selection across runs.

apps/backend/prisma/migrations/20251212180000_email_outbox/migration.sql (2)

92-95: Priority ordering vs indexes: priority ASC likely fights “high priority first”
priority assigns 100 for high-priority (Line 93), but EmailOutbox_sending_idx is (tenancyId, priority, scheduledAt) (Line 248) and EmailOutbox_ordering_idx stores priority ASC (Line 256). If the processor selects “highest priority first”, these indexes won’t support that ordering well (and may encourage lowest-priority-first scans).

Also applies to: 248-258

---

251-257: Double-check scheduledAtIfNotYetQueued DESC aligns with “send oldest first”
scheduledAtIfNotYetQueued is scheduledAt when not queued (Line 109-111), but ordering_idx uses scheduledAtIfNotYetQueued DESC (Line 255). If you intend FIFO by scheduled time, this likely wants ASC (or you need matching query ORDER BY).

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

The variables internalTenancy and emailConfig are fetched unconditionally but never used because the email sending functionality is disabled (line 72 throws immediately). The getSharedEmailConfig call invokes getEnvVariable for email configuration variables (STACK_EMAIL_HOST, etc.) without defaults, which will throw an error if those environment variables aren't set. This causes the endpoint to fail with a confusing error about missing email config even though email sending is disabled. These fetches should be removed or moved inside the conditional block.

apps/backend/prisma/migrations/20251212183000_migrate_sent_email/migration.sql (2)

7-9: Dropping SentEmail will discard “orphaned tenancy” rows (if any) without migrating them.
The WHERE EXISTS (Tenancy…) filter intentionally skips any SentEmail whose tenancyId no longer exists, but DROP TABLE … "SentEmail" will still remove them. If that’s intended cleanup, consider making it explicit (e.g., pre-delete with a comment / sanity-count), or gate the DROP on “no remaining rows”.

Also applies to: 140-140

---

14-15: Add a deterministic ORDER BY to the 10k batching selection.
LIMIT 10000 without ORDER BY makes each batch nondeterministic, which can complicate debugging/rollbacks. Deterministic ordering is cheap here and keeps re-runs predictable.

 WITH to_migrate AS (
     SELECT se."tenancyId", se."id"
     FROM "SentEmail" se
@@
     AND NOT EXISTS (
         SELECT 1 FROM "EmailOutbox" eo 
         WHERE eo."tenancyId" = se."tenancyId" AND eo."id" = se."id"
     )
+    ORDER BY se."createdAt" ASC, se."tenancyId" ASC, se."id" ASC
     LIMIT 10000
 ),

Also applies to: 128-133

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro