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

177-183: Consider logging when timestamp parsing falls back to current time.

The silent fallback to new Date() is a reasonable degradation strategy, but it could mask issues if Resend changes their timestamp format. Logging when the fallback is used would help with debugging unexpected matching behavior.

🔧 Optional: add observability for fallback case

 function parseEventTimestamp(raw: string | undefined): Date {
   if (raw) {
     const parsed = new Date(raw);
     if (!isNaN(parsed.getTime())) return parsed;
+    captureError("resend-webhook-timestamp-parse-failure", new StackAssertionError("Failed to parse Resend webhook timestamp, using current time", { raw }));
   }
   return new Date();
 }

🤖 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 177 - 183, Update parseEventTimestamp to log when it fails to parse
the provided raw timestamp and falls back to new Date(): detect the case when
raw is truthy but new Date(raw) is invalid, and call the existing logger (or
import/create one) to emit a warning including the raw value and a short context
message before returning new Date(); keep behavior unchanged when raw is
undefined or valid. Ensure the log uses the parseEventTimestamp function name
and the raw timestamp value to aid debugging.

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

733-745: Consider case-insensitive host matching for robustness.

The substring check host.includes("resend") works for typical Resend SMTP hosts (e.g., smtp.resend.com), but could miss edge cases if the host is configured with different casing. A case-insensitive check would be more defensive.

🔧 Optional: case-insensitive check

       // Success - mark as sent (don't increment sendRetries since this wasn't a failure)
       // Resend delivers async webhook events (email.delivered/bounced/...); everything else is fire-and-forget.
-      const providerCanDeliverInfo = context.emailConfig.host.includes("resend");
+      const providerCanDeliverInfo = context.emailConfig.host.toLowerCase().includes("resend");

🤖 Prompt for AI Agents

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

In `@apps/backend/src/lib/email-queue-step.tsx` around lines 733 - 745, The
providerCanDeliverInfo calculation uses a case-sensitive substring check
(context.emailConfig.host.includes("resend")); make it case-insensitive by
normalizing the host string (e.g., context.emailConfig.host?.toLowerCase())
before checking for "resend" or use a case-insensitive regex, and guard against
null/undefined host to avoid crashes; update the code that sets
providerCanDeliverInfo and leave the rest of the emailOutbox.update call
unchanged.

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

234-239: Silent drop for unknown type values.

When payload.type is set to something we don’t recognise (neither domain.updated nor a known email.*), we currently return 200 with no trace. One captureError (or at minimum a console.warn) before falling through would make it obvious when Resend adds a new event kind or when a misrouted webhook hits this endpoint.

🤖 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 234 - 239, The handler currently silently ignores unknown
payload.type values; before returning 200 in the else branch that computes const
kind = eventType ? emailEventKindFromType(eventType) : null, add a warning/error
capture so unknown event kinds are visible: call captureError (or at minimum
console.warn) including the raw payload.type and payload body when
emailEventKindFromType returns null (or eventType is falsy) so operators see
when an unrecognized or new Resend event arrives; update the branch around
emailEventKindFromType and processEmailDeliveryEvent to log/capture and then
continue returning 200.

---

81-98: email.complained only writes markedAsSpamAt — consider surfacing a suppression signal too.

A complained event means the recipient hit the spam button; in most production setups you’d want to (a) add the address to a suppression list and/or (b) auto-unsubscribe them from the relevant notification category so you don’t keep sending and further hurt sender reputation. Right now this only updates a timestamp column.

Fine to defer to a follow-up PR, but worth tracking — silently continuing to send to a complained address is both a deliverability risk and, depending on jurisdiction, a compliance one.

Want me to open a follow-up issue for wiring email.complained into the notification-preferences / suppression flow?

🤖 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 81 - 98, In processEmailDeliveryEvent, when kind === "complained"
(currently only setting markedAsSpamAt), also record a suppression/unsubscribe
signal: call or implement a suppression helper (e.g.,
addToSuppressionList(email) or upsertSuppressionRecord) and invoke the
notification-preferences/unsubscribe flow (e.g.,
unsubscribeRecipientFromNotifications(recipientEmail, { source:
"resend.complained" })) for each recipient before returning; ensure the
suppression call uses the same recipient(s) derived from rawTo and include the
payload/context for auditing so complaints both set markedAsSpamAt and prevent
further sends.

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

733-745: Extract the "smtp.resend.com" literal into a shared constant.

The same host literal is hardcoded in apps/backend/src/lib/emails.tsx (managed-email config) and now here; if the managed host ever changes (or is extended to e.g. an EU-region variant like smtp.eu.resend.com), both sites must be edited in lockstep and the canHaveDeliveryInfo contract silently breaks on mismatch. A single exported constant (or a small providerCanDeliverInfo(emailConfig) helper co-located with getEmailConfig) would keep them in sync.

♻️ Sketch

-      // Resend delivers async webhook events (email.delivered/bounced/...); everything else is fire-and-forget.
-      const providerCanDeliverInfo = context.emailConfig.host === "smtp.resend.com";
+      // Resend delivers async webhook events (email.delivered/bounced/...); everything else is fire-and-forget.
+      const providerCanDeliverInfo = context.emailConfig.host === RESEND_SMTP_HOST;

with RESEND_SMTP_HOST exported from lib/emails.tsx and reused in the managed-email branch there.

🤖 Prompt for AI Agents

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

In `@apps/backend/src/lib/email-queue-step.tsx` around lines 733 - 745, Extract
the hardcoded "smtp.resend.com" into a single exported symbol and reuse it from
both places; e.g., add and export RESEND_SMTP_HOST (or a small helper
providerCanDeliverInfo(emailConfig)) next to getEmailConfig in lib/emails.tsx,
then replace the literal in email-queue-step.tsx where providerCanDeliverInfo is
computed and in the managed-email branch in lib/emails.tsx so both files import
and use the shared constant/helper to determine canHaveDeliveryInfo.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes