apps/dashboard/src/components/form-dialog.tsx (1)

71-80: Inconsistent equality operators: == vs === for boolean comparison.

Lines 73 and 78 use == for comparing typeof props.okButton with "boolean", while the equivalent code in SmartFormDialog (Lines 22, 27) uses ===. This is functionally equivalent here since typeof always returns a string, but the inconsistency is unnecessary.

Suggested fix for consistency

-    ...(typeof props.okButton == "boolean" ? {} : props.okButton),
+    ...(typeof props.okButton === "boolean" ? {} : props.okButton),
     props: {
       form: formId,
       type: "submit" as const,
       loading: submitting,
-      ...((typeof props.okButton == "boolean") ? {} : props.okButton?.props),
+      ...((typeof props.okButton === "boolean") ? {} : props.okButton?.props),
     },

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/dashboard/src/components/form-dialog.tsx` around lines 71 - 80, The code
in the okButton construction uses loose equality (typeof props.okButton ==
"boolean") in two places; change both to strict equality (===) to match the
style used in SmartFormDialog and maintain consistency. Update the two checks
inside the okButton object that reference typeof props.okButton to use ===;
ensure behavior remains the same for props.okButton, okButton.props merging, and
that variables like formId and submitting are untouched.

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

1087-1096: Duplicated managed SMTP constants across emails.tsx and config.tsx.

The Resend SMTP host (smtp.resend.com), port (465), and username (resend) are hardcoded identically in both apps/backend/src/lib/emails.tsx (Lines 115-117) and here. Consider extracting these into a shared constant to keep them in sync.

Also note: emails.tsx throws a StackAssertionError if managedSubdomain or managedSenderLocalPart is missing, while this code silently falls back to senderEmail (Line 1096). This divergence may be intentional for the read-path, but worth confirming.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/config.tsx` around lines 1087 - 1096, Extract the
duplicated Resend SMTP values (host "smtp.resend.com", port 465, username
"resend") into a single shared constant (e.g., RESEND_SMTP = { host, port,
username }) exported from a common module and replace the hardcoded literals in
both apps/backend/src/lib/config.tsx (where renderedConfig.emails.server is
used) and apps/backend/src/lib/emails.tsx to reference that constant; while
doing this, reconcile the behavioral divergence for missing
managedSubdomain/managedSenderLocalPart by choosing one consistent approach
(either preserve the current fallback to senderEmail in the config path or make
config.tsx mirror emails.tsx and throw a StackAssertionError) and implement that
consistent behavior in both places (update any conditionals around
managedSenderLocalPart/managedSubdomain and error handling to match the chosen
approach).

apps/backend/src/app/api/latest/integrations/resend/webhooks/route.tsx (1)

78-84: Consider using StatusError(400) for missing webhook payload fields.

When domainId or providerStatusRaw is missing from a domain.updated payload, the code throws StackAssertionError which surfaces as a 500. Since this is externally-triggered input (from Resend), a 400 may be more accurate. That said, if these fields are contractually guaranteed by Resend's API for domain.updated events, treating their absence as an assertion failure is defensible.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/app/api/latest/integrations/resend/webhooks/route.tsx`
around lines 78 - 84, Replace the 500-level StackAssertionError thrown when
payload.data?.id or payload.data?.status is missing with a 400 StatusError to
reflect a bad external request: in the block that checks domainId and
providerStatusRaw (variables domainId and providerStatusRaw), throw a new
StatusError(400, "Resend webhook payload missing required domain fields") and
include the original payload in the error metadata or message instead of using
StackAssertionError so the response returns 400 for malformed Resend webhooks.

apps/e2e/tests/backend/endpoints/api/v1/internal/managed-email-onboarding.test.ts (1)

37-121: Add explicit client-access rejection tests for /check, /list, and /apply too.

The suite currently hardens access control only for /setup; adding the same negative checks for the other new endpoints will better protect against authorization regressions.

As per coding guidelines, **/apps/e2e/**/*.{ts,tsx}: ALWAYS add new E2E tests when you change the API or SDK interface. Generally, err on the side of creating too many tests.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/e2e/tests/backend/endpoints/api/v1/internal/managed-email-onboarding.test.ts`
around lines 37 - 121, Add negative E2E assertions in
apps/e2e/tests/backend/endpoints/api/v1/internal/managed-email-onboarding.test.ts
to ensure client-level access is rejected for the remaining endpoints
(/api/v1/internal/emails/managed-onboarding/check, /list, and /apply). For each
endpoint create a short test (or extend the existing suite) that calls
niceBackendFetch with accessType: "client" and the same minimal body used in the
positive tests (use domain_id/subdomain/sender_local_part where required) and
assert the response indicates authorization failure (e.g., status is 401/403 or
otherwise rejected by your API). Ensure the tests reference the same endpoint
paths and mimic the request shapes used in the passing admin tests so they fail
due to access level rather than request shape.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/emails/page-client.tsx (1)

952-956: ⚠️ Potential issue | 🟡 Minor

Use == null checks instead of falsy checks for SMTP field validation.

!emailServerConfig.port treats 0 as missing. As per coding guidelines, prefer explicit null/undefined checks.

🔧 Proposed fix

-        if (!emailServerConfig.host) missingFields.push("host");
-        if (!emailServerConfig.port) missingFields.push("port");
-        if (!emailServerConfig.username) missingFields.push("username");
+        if (emailServerConfig.host == null) missingFields.push("host");
+        if (emailServerConfig.port == null) missingFields.push("port");
+        if (emailServerConfig.username == null) missingFields.push("username");

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/emails/page-client.tsx
around lines 952 - 956, In the provider !== "managed" block, the current
validation uses falsy checks (e.g., if (!emailServerConfig.port)) which
incorrectly treats valid values like 0 as missing; update the checks to explicit
null/undefined comparisons (e.g., if (emailServerConfig.port == null)) for host,
port, and username so only null or undefined are considered missing and still
push the same keys into missingFields; locate these checks on the
emailServerConfig object and replace !emailServerConfig.host /
!emailServerConfig.port / !emailServerConfig.username with == null variants.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

apps/backend/src/lib/managed-email-onboarding.tsx (3)

179-185: ⚠️ Potential issue | 🟠 Major

Add explicit timeouts/abort signals to outbound DNSimple/Resend requests.

These fetch calls run on request paths without a timeout (Line 182 and similar), so upstream hangs can pin workers and degrade API reliability. Please route all provider calls through a timeout-aware helper and pass signal.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-onboarding.tsx` around lines 179 - 185,
The outgoing fetch in listDnsimpleZones (and other provider call sites such as
Resend requests) lacks an abort/timeout; wrap these calls with a timeout-aware
helper (e.g., fetchWithTimeout or a shared requestWithAbort) and pass an
AbortSignal into fetch via the options.signal property so upstream hangs can't
pin workers; update listDnsimpleZones to accept or create an AbortController (or
accept a signal parameter) and call fetch(..., { method: "GET", headers:
getDnsimpleHeaders(), signal }) or delegate to the shared helper that enforces a
timeout and exposes the signal to callers.

---

551-573: ⚠️ Potential issue | 🟠 Major

Make setup idempotent before external side effects.

createResendDomain/DNS operations happen before createManagedEmailDomain. If the DB write fails, retries can hit “already exists” and become unrecoverable for the same subdomain. Persist a pending row first (or add robust external-resource reuse on retry).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-onboarding.tsx` around lines 551 - 573,
The flow performs external side effects (createResendDomain,
createOrReuseDnsimpleZone, upsertDnsimpleResendRecords,
getDnsimpleZoneNameServers) before recording the managed domain in the DB, which
breaks idempotency on retries; change createManagedEmailDomain to persist a
pending row for normalizedSubdomain first (status "pending_verification" and
without resendDomainId), then perform
createResendDomain/createOrReuseDnsimpleZone/upsertDnsimpleResendRecords/getDnsimpleZoneNameServers,
and finally update the persisted row with resendDomainId, nameServerRecords and
final status (or reuse existing row if present). Ensure
createManagedEmailDomain/managedDomainToSetupResult logic supports
creating/updating the pending row and handles existing rows to avoid duplicate
external resource errors on retry.

---

608-635: ⚠️ Potential issue | 🟠 Major

Guard apply with an atomic status transition before key creation.

Concurrent apply requests can both pass the verified check and mint multiple scoped keys before Line 634 updates status. Use an atomic conditional transition (e.g., verified -> applying) and proceed only when exactly one caller acquires it.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-onboarding.tsx` around lines 608 - 635,
Before creating keys, perform an atomic conditional status transition on the
managed domain from "verified" to "applying" so only one caller proceeds: use
getManagedEmailDomainByResendDomainId to locate the domain, then run an atomic
update (e.g., SQL/ORM conditional update or compare-and-swap) that sets status =
"applying" WHERE id = domain.id AND status = "verified" and check the
affected-rows; if the update did not affect a row, re-fetch the domain status
and return/throw appropriately (e.g., return current status or 409), otherwise
proceed to call createResendScopedKey, saveManagedEmailProviderConfig, then
markManagedEmailDomainApplied (or set final status) to complete the flow; ensure
you reference domain.id, domain.resendDomainId, domain.subdomain and tenancy.id
when performing the atomic update and subsequent operations.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

apps/backend/src/lib/managed-email-domains.tsx (1)

47-61: Silent fallback in status mappers — previously flagged.

Both dbStatusToStatus and statusToDbStatus still fall through to a default return value ("failed" / "FAILED") rather than throwing on unknown enum values.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-domains.tsx` around lines 47 - 61, The two
mapper functions dbStatusToStatus and statusToDbStatus currently return a silent
default ("failed"/"FAILED") for unknown enum values; change them to be
exhaustive by throwing a clear error when an unexpected status is encountered
(e.g., throw new Error including the incoming status value) instead of falling
through, so update dbStatusToStatus and statusToDbStatus to throw on any
unrecognized input to surface programmer errors.

apps/backend/src/lib/managed-email-onboarding.tsx (5)

271-282: DNSimple DNS record listing is also page-limited — previously flagged.

listDnsimpleDnsRecords hard-codes page=1&per_page=100, mirroring the same pagination gap flagged for listDnsimpleZones.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-onboarding.tsx` around lines 271 - 282,
The function listDnsimpleDnsRecords currently hard-codes page=1&per_page=100
causing missed records; change it to page through all results and return the
aggregated array. In listDnsimpleDnsRecords, repeatedly call fetch for the zone
records (using getDnsimpleBaseUrl, getDnsimpleAccountId and getDnsimpleHeaders)
advancing the page parameter (or using Link/next from response.headers if
available) and parse each response with
parseDnsimpleJsonOrThrow<DnsimpleDnsRecord[]>; accumulate results into a single
array and stop when a page returns an empty array (or no next link). Ensure the
final promise resolves to the full combined DnsimpleDnsRecord[].

---

445-468: Missing validation of body.id / body.name before use — previously flagged.

The cast at line 445 does not validate that body.id and body.name are non-empty strings before they are used at line 447 (URL interpolation) and line 459 (error context).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-onboarding.tsx` around lines 445 - 468,
Validate that body.id and body.name are present and non-empty strings before
using them: check typeof body.id === "string" && body.id.trim() !== "" (and same
for body.name) immediately after parsing the JSON, and if validation fails,
throw a StackAssertionError (or return a clear error) instead of proceeding to
call fetch for verifyResponse or interpolating the URL; ensure any thrown error
includes the original response text/context to aid debugging and only use
body.id/body.name when the checks pass.

---

551-573: Non-idempotent setup: external side-effects before DB persistence — previously flagged.

Resend domain creation and DNSimple zone setup happen before the DB row is committed, making retries after a partial failure unrecoverable.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-onboarding.tsx` around lines 551 - 573,
The current flow calls createResendDomain, createOrReuseDnsimpleZone,
upsertDnsimpleResendRecords and getDnsimpleZoneNameServers before persisting
with createManagedEmailDomain, which makes retries non-idempotent; change the
flow to persist a DB row first (call createManagedEmailDomain with a provisional
status like "creating" or "pending") using the same fields except external IDs,
then perform external side-effects (createResendDomain,
createOrReuseDnsimpleZone, upsertDnsimpleResendRecords,
getDnsimpleZoneNameServers), and finally update the persisted row with
resendDomain.id, nameServerRecords and the final status (verified or
pending_verification); ensure managedDomainToSetupResult reads the updated row
or return the updated object after the DB update so partial failures can be
retried safely.

---

179-190: Missing HTTP timeouts on all fetch calls — previously flagged.

All DNSimple and Resend fetch calls (here and at lines 196, 209, 241, 273, 307, 423, 473) lack an AbortSignal / timeout, allowing upstream hangs to pin worker threads.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-onboarding.tsx` around lines 179 - 190,
The fetch in listDnsimpleZones (and the other DNSimple/Resend fetches flagged)
lacks a timeout/AbortSignal; update listDnsimpleZones to create an
AbortController with a short configurable timeout, pass controller.signal into
fetch, clear the timeout on success, and reject/throw a clear timeout error when
aborted; follow the same pattern for the other functions that call fetch (the
other DNSimple/Resend calls referenced), ensuring you still call
parseDnsimpleJsonOrThrow/getDnsimpleHeaders as before and that the controller is
cleaned up to avoid leaks.

---

608-636: Race condition between verified check and createResendScopedKey — previously flagged.

Concurrent applyManagedEmailProvider calls can both pass the domain.status !== "verified" guard and mint duplicate scoped Resend keys before markManagedEmailDomainApplied serialises them.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-onboarding.tsx` around lines 608 - 636,
Current code can mint duplicate Resend keys because multiple callers can pass
the domain.status === "verified" guard before one marks it applied; fix by
making the transition from "verified" to a reserved state atomic and only
creating the scoped key after you win that atomic update. Update the flow around
getManagedEmailDomainByResendDomainId/createResendScopedKey/markManagedEmailDomainApplied/saveManagedEmailProviderConfig
so that you: attempt a conditional DB update (e.g. markManagedEmailDomainApplied
or a new method) that sets status FROM "verified" TO "applying" (or directly to
"applied") only if the current status === "verified" and returns whether the
update succeeded; if the conditional update fails, re-fetch the domain and
return its current status; if it succeeds, createResendScopedKey and then
persist the provider config and finalize the status to "applied" (or update
"applying"→"applied") — or alternatively implement SELECT ... FOR UPDATE
wrapping the read/create/save sequence in a single transaction so only one
caller can create the key. Use the existing function names
getManagedEmailDomainByResendDomainId, createResendScopedKey and
markManagedEmailDomainApplied (or extend markManagedEmailDomainApplied to
perform the conditional/CAS update) so callers cannot race.

apps/backend/src/lib/managed-email-onboarding.tsx (2)

257-268: match[1] is string | undefined — add a defensive guard per coding guidelines.

TypeScript types regex capture groups as string | undefined. Even though the pattern guarantees a capture when match is truthy, the guidelines require explicit null/undefined checks or ?? throwErr(...) rather than relying on implicit regex semantics.

♻️ Proposed fix

-    const nameServer = normalizeRecordContent(match[1]);
+    const nameServer = normalizeRecordContent(match[1] ?? throwErr("NS regex matched but capture group 1 was undefined"));

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-onboarding.tsx` around lines 257 - 268,
The regex capture match[1] in the loop inside the function reading rawZoneFile
can be undefined even when match is truthy; update the loop to defensively
handle that by extracting the capture into a local variable (e.g., const
captured = match[1]) and then either continue when it's null/undefined or throw
via a helper (per guidelines) before calling normalizeRecordContent and adding
to nameServerSet; ensure you reference match, normalizeRecordContent, and
nameServerSet when making the check so no implicit assumption about match[1]
remains.

---

103-110: Use explicit != null instead of boolean truthiness check for zoneSubdomainLabel.

zoneLabels[0] is string | undefined. The coding guidelines prefer explicit null/undefined checks (zoneSubdomainLabel != null) over boolean coercions (if (zoneSubdomainLabel && ...)) to avoid treating empty-string edge cases silently.

♻️ Proposed fix

-  if (zoneSubdomainLabel && normalizedName.endsWith(`.${zoneSubdomainLabel}`)) {
+  if (zoneSubdomainLabel != null && normalizedName.endsWith(`.${zoneSubdomainLabel}`)) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-onboarding.tsx` around lines 103 - 110,
The boolean truthiness check for zoneSubdomainLabel should be replaced with an
explicit null/undefined check to avoid treating an empty string as falsy; in the
block that computes zoneLabels/zoneSubdomainLabel (references: zoneLabels,
zoneSubdomainLabel, normalizedZoneName, normalizedName,
recordWithoutZoneSubdomainLabel), change the condition from "if
(zoneSubdomainLabel && normalizedName.endsWith(...))" to use "zoneSubdomainLabel
!= null && normalizedName.endsWith(...)" so empty-string values are handled
correctly while still guarding against null/undefined.

apps/backend/src/lib/managed-email-domains.tsx (1)

108-108: Prefer ?? throwErr(...) over non-null assertion !.

The length guard above makes rows[0] safe at runtime, but the project guidelines ask for ?? throwErr(...) over ! so the assumption is explicit. The same applies to lines 121, 173, and 191.

♻️ Proposed refactor (all four sites)

-  return mapRow(rows[0]!);    // line 108
+  return mapRow(rows[0] ?? throwErr("getManagedEmailDomainByTenancyAndSubdomain: expected row after length check"));

-  return mapRow(rows[0]!);    // line 121
+  return mapRow(rows[0] ?? throwErr("getManagedEmailDomainByResendDomainId: expected row after length check"));

-  return mapRow(rows[0]!);    // line 173
+  return mapRow(rows[0] ?? throwErr("updateManagedEmailDomainWebhookStatus: expected RETURNING row"));

-  return mapRow(rows[0]!);    // line 191
+  return mapRow(rows[0] ?? throwErr("markManagedEmailDomainApplied: expected RETURNING row"));

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-domains.tsx` at line 108, Replace the
non-null assertion used when passing DB rows into mapRow with an explicit
null-coalescing throw so the assumption is explicit: change occurrences like
return mapRow(rows[0]!) to return mapRow(rows[0] ?? throwErr("expected row not
found")) (use the project throwErr helper and a concise message), and apply the
same pattern at the other sites that pass rows[0] into mapRow (the occurrences
flagged at lines 121, 173, and 191).

Configuration used: defaults

Review profile: CHILL

Plan: Pro

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/emails/page-client.tsx (2)

977-981: Falsy presence checks for SMTP fields — still unaddressed.

!emailServerConfig.host, !emailServerConfig.port, and !emailServerConfig.username treat 0/"" as missing. Use explicit == null checks. This was previously flagged.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/emails/page-client.tsx
around lines 977 - 981, Replace the falsy checks that treat valid values like 0
or "" as missing by using explicit null/undefined checks: in the block that
inspects emailServerConfig when emailServerConfig.provider !== "managed", change
the conditions for host, port, and username from
"!emailServerConfig.host"/"!emailServerConfig.port"/"!emailServerConfig.username"
to checks that test for null or undefined (e.g., emailServerConfig.host ==
null), and continue pushing the same field names onto missingFields when those
explicit checks indicate absence; update the logic in the surrounding
conditional that references emailServerConfig/provider to ensure behavior is
unchanged for non-managed providers.

---

240-256: managedSubdomain and managedSenderLocalPart still render as "undefined" when not set.

The past fix was applied to earlier commits but the current code at Lines 245 and 254 still renders these fields directly without a null guard. When provider === "managed" but the fields are not yet populated, React will render the literal string "undefined".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/emails/page-client.tsx
around lines 240 - 256, The two spans displaying emailConfig.managedSubdomain
and emailConfig.managedSenderLocalPart can render the literal "undefined" when
provider === "managed" but those fields are not yet set; update the rendering in
page-client.tsx so the values are null-guarded (e.g., render an empty string or
a placeholder like "—" when emailConfig.managedSubdomain or
emailConfig.managedSenderLocalPart is undefined or falsy). Keep the existing
provider === "managed" checks and change only the span contents that reference
emailConfig.managedSubdomain and emailConfig.managedSenderLocalPart to safely
coalesce to a fallback value.

apps/backend/src/lib/managed-email-onboarding.tsx (3)

445-447: body.id used without null-check before the verify fetch.

This was previously flagged and remains unaddressed. Validate body.id and body.name exist before constructing the verification URL.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-onboarding.tsx` around lines 445 - 447,
Validate that the parsed response object (the variable named body from the const
body = await response.json(...) assignment) contains non-empty body.id and
body.name before calling
fetch(`https://api.resend.com/domains/${body.id}/verify`); add a guard that
checks both fields, log or throw a clear error (or return early) if either is
missing, and only construct/perform the verify fetch when body.id and body.name
are present so you never interpolate an undefined id into the verification URL.

---

179-191: HTTP timeout and pagination concerns still unaddressed.

The fetch-without-timeout and page=1 hard-coded pagination issues were previously flagged and remain in the current code.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-onboarding.tsx` around lines 179 - 191, In
listDnsimpleZones: add an HTTP timeout using AbortController (or a shared
fetch-with-timeout helper) so the fetch call respects a configurable timeout
instead of hanging, and replace the hard-coded single-page fetch with paginated
fetching that loops (incrementing page) to accumulate results (use per_page as a
constant or config and stop when returned page length < per_page or when no more
pages); continue to call getDnsimpleBaseUrl, getDnsimpleAccountId,
getDnsimpleHeaders, and parseDnsimpleJsonOrThrow for each page and filter the
final accumulated list with normalizeDomainName(zone.name) ===
normalizeDomainName(subdomain).

---

551-573: External resources created before DB row persisted — still unaddressed.

The idempotency concern (Resend domain + DNSimple zone created before createManagedEmailDomain) was previously raised and remains in the current code.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-onboarding.tsx` around lines 551 - 573,
External resources (createResendDomain, createOrReuseDnsimpleZone,
upsertDnsimpleResendRecords, getDnsimpleZoneNameServers) are created before
persisting the DB row (createManagedEmailDomain), risking orphaned resources if
DB insert fails; change flow to first persist a provisional managed-email row
(e.g., status "provisioning" or similar) via createManagedEmailDomain, then call
createResendDomain/createOrReuseDnsimpleZone/upsertDnsimpleResendRecords/getDnsimpleZoneNameServers,
and finally update that row with resendDomainId, nameServerRecords and final
status (or implement compensating cleanup to delete resendDomain and DNSimple
zone on DB failure if you prefer rollback instead of provisional row); update
managedDomainToSetupResult usage to read from the persisted/updated row.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/emails/page-client.tsx (3)

991-1008: Redundant inner provider === "managed" checks after the outer discriminant — consider restructuring.

The outer condition at Line 992 already narrows to provider === 'resend' || provider === 'managed'. The five inner eslint-disable-next-line @typescript-eslint/no-unnecessary-condition`` comments on repeated provider === "managed" checks indicate TypeScript already knows these are redundant. Extracting the managed branch into its own `if/else` block would eliminate the suppressed warnings and make the intent explicit.

♻️ Proposed refactor

-      // eslint-disable-next-line `@typescript-eslint/no-unnecessary-condition`
-      const emailConfig: AdminEmailConfig = emailServerConfig.provider === 'resend' || emailServerConfig.provider === 'managed' ? {
-        type: 'resend',
-        // eslint-disable-next-line `@typescript-eslint/no-unnecessary-condition`
-        host: emailServerConfig.provider === "managed" ? "smtp.resend.com" : (emailServerConfig.host ?? throwErr("Email host is missing")),
-        // eslint-disable-next-line `@typescript-eslint/no-unnecessary-condition`
-        port: emailServerConfig.provider === "managed" ? 465 : (emailServerConfig.port ?? throwErr("Email port is missing")),
-        // eslint-disable-next-line `@typescript-eslint/no-unnecessary-condition`
-        username: emailServerConfig.provider === "managed" ? "resend" : (emailServerConfig.username ?? throwErr("Email username is missing")),
-        password: emailServerConfig.password ?? throwErr("Email password is missing"),
-        // eslint-disable-next-line `@typescript-eslint/no-unnecessary-condition`
-        senderName: emailServerConfig.provider === "managed" ? project.displayName : (emailServerConfig.senderName ?? throwErr("Email sender name is missing")),
-        // eslint-disable-next-line `@typescript-eslint/no-unnecessary-condition`
-        senderEmail: emailServerConfig.provider === "managed"
-          ? (emailServerConfig.managedSubdomain && emailServerConfig.managedSenderLocalPart
-            ? `${emailServerConfig.managedSenderLocalPart}@${emailServerConfig.managedSubdomain}`
-            : throwErr("Managed sender config is missing"))
-          : (emailServerConfig.senderEmail ?? throwErr("Email sender email is missing")),
-      } : {
+      let emailConfig: AdminEmailConfig;
+      if (emailServerConfig.provider === 'managed') {
+        emailConfig = {
+          type: 'resend',
+          host: 'smtp.resend.com',
+          port: 465,
+          username: 'resend',
+          password: emailServerConfig.password ?? throwErr("Email password is missing"),
+          senderName: project.displayName,
+          senderEmail: (emailServerConfig.managedSubdomain && emailServerConfig.managedSenderLocalPart)
+            ? `${emailServerConfig.managedSenderLocalPart}@${emailServerConfig.managedSubdomain}`
+            : throwErr("Managed sender config is missing"),
+        };
+      } else if (emailServerConfig.provider === 'resend') {
+        emailConfig = {
+          type: 'resend',
+          host: emailServerConfig.host ?? throwErr("Email host is missing"),
+          port: emailServerConfig.port ?? throwErr("Email port is missing"),
+          username: emailServerConfig.username ?? throwErr("Email username is missing"),
+          password: emailServerConfig.password ?? throwErr("Email password is missing"),
+          senderName: emailServerConfig.senderName ?? throwErr("Email sender name is missing"),
+          senderEmail: emailServerConfig.senderEmail ?? throwErr("Email sender email is missing"),
+        };
+      } else {
+        emailConfig = {
           type: 'standard',
           host: emailServerConfig.host ?? throwErr("Email host is missing"),
           port: emailServerConfig.port ?? throwErr("Email port is missing"),
           username: emailServerConfig.username ?? throwErr("Email username is missing"),
           password: emailServerConfig.password ?? throwErr("Email password is missing"),
           senderName: emailServerConfig.senderName ?? throwErr("Email sender name is missing"),
           senderEmail: emailServerConfig.senderEmail ?? throwErr("Email sender email is missing"),
-      };
+        };
+      }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/emails/page-client.tsx
around lines 991 - 1008, The emailConfig construction repeats provider ===
"managed" checks inside a branch already guarded by emailServerConfig.provider
=== 'resend' || 'managed', causing redundant conditions and suppressed ESLint
warnings; refactor by splitting the logic into two explicit branches (e.g., if
(emailServerConfig.provider === 'managed') { ... } else { ... }) when building
emailConfig so the managed-specific values (host, port, username, senderName,
senderEmail managed-subdomain logic) are set in the managed branch and the
resend/default values use the other branch, referencing the same identifiers
(emailConfig, emailServerConfig, project, throwErr) to remove the unnecessary
inner provider checks and eslint-disable comments.

---

787-793: Using toast for the "managed unchanged" path hides feedback and is UX-confusing.

When a user selects "managed" and clicks Save, the form closes and a toast briefly appears. The user gets no clear indication that nothing was saved. Per the AGENTS.md guidance, blocking feedback should use alerts (not toasts). A better pattern is to prevent form submission with an inline <Alert> inside the render block (already shown at Lines 873–887) and not allow the form to "submit" the managed type at all.

💡 Suggested direction

Return "prevent-close" from the managed branch and display the informational content inline (already done in the render block at Lines 873–887) rather than using a toast + silent close.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/emails/page-client.tsx
around lines 787 - 793, In the branch that handles values.type === 'managed'
(the save/submit handler where the toast is currently shown), remove the toast
call and instead return the sentinel string "prevent-close" so the parent/form
does not close; rely on the existing inline Alert in the component's render
block to show the informational message for the managed path. Specifically, edit
the handler (the function that checks values.type === 'managed') to stop
performing a close or success toast, return "prevent-close" from that branch,
and ensure no other code treats that branch as a successful submit.

---

198-205: "Managed Setup" button is always visible regardless of the current email provider.

Unlike the "Test" button (which is hidden for shared providers), the "Managed Setup" button appears even when the project is using shared or custom SMTP email. Consider conditionally showing it (e.g., hide when emailConfig.isShared or when emailConfig.provider === "managed" and already applied), to reduce UI noise.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/emails/page-client.tsx
around lines 198 - 205, The "Managed Setup" button should be conditionally
rendered like the "Test" button: update the render around
ManagedEmailSetupDialog so it only shows when the project is not using a shared
provider and is not already using the managed provider (e.g., wrap
ManagedEmailSetupDialog in a check such as !emailConfig.isShared &&
emailConfig.provider !== 'managed'); reference the ManagedEmailSetupDialog
component and the emailConfig object (emailConfig.isShared and
emailConfig.provider) to locate and implement the conditional rendering.

apps/backend/src/lib/managed-email-onboarding.tsx (1)

638-657: Consider logging when no domain row is found for a webhook event.

updateManagedEmailDomainWebhookStatus may silently affect 0 rows if the resendDomainId is unknown (e.g., stale webhook for a deleted or externally-created domain). A structured log at this point would aid debugging without changing the webhook's success response contract.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/managed-email-onboarding.tsx` around lines 638 - 657, In
processResendDomainWebhookEvent, capture the result from
updateManagedEmailWebhookStatus (or modify updateManagedEmailDomainWebhookStatus
to return the number of affected rows) and if it indicates 0 rows updated, emit
a structured warning log (e.g., using processLogger.warn or your request logger)
that includes resendDomainId (options.domainId), providerStatusRaw, computed
mappedStatus, and errorMessage; reference the symbols
processResendDomainWebhookEvent and updateManagedEmailDomainWebhookStatus when
making the change so the caller checks the returned affected-row count and logs
the stale/unknown domain webhook event.

Configuration used: defaults

Review profile: CHILL

Plan: Pro