upgrade production ePDS to v0.7.0#210
Conversation
The client-branded OTP delivery log exposed its recipient under the generic to field, while related authentication logs use email. This made structured log queries inconsistent.\n\nPublish the same recipient value under email and document the operator-facing field rename.\n\nCo-authored-by: OpenAI Codex <codex@openai.com>
The first pass updated only the client-branded delivery log and overlooked the three other sendMail call sites. That left standard sign-in, welcome, and backup verification deliveries without the same structured recipient context.\n\nAdd an email field to the delivery log for every sendMail path while retaining Nodemailer's required to envelope property.\n\nCo-authored-by: OpenAI Codex <codex@openai.com>
fix(auth-service): log email recipients consistently
Store Resend email lifecycle events idempotently by Svix ID and expose delivery latency and outcome metrics. Share the ten-minute OTP lifetime between Better Auth and the latency threshold so the two cannot drift. Refs #185 Co-authored-by: OpenAI Codex <noreply@openai.com>
Add a raw-body webhook endpoint that verifies Svix signatures before validating and persisting supported Resend email events. Retries are acknowledged idempotently and delayed-delivery events are surfaced in logs. Refs #185 Co-authored-by: OpenAI Codex <noreply@openai.com>
Document the webhook URL, event subscriptions, signing secret, metrics output, and the required live SMTP verification. Propagate RESEND_WEBHOOK_SECRET into generated auth-service environments and add release notes. Refs #185 Co-authored-by: OpenAI Codex <noreply@openai.com>
Clarify that ePDS supports any SMTP provider and expose the Resend route and metrics only after an operator opts in with a webhook secret. Bound the optional integration with dedicated rate limiting, 30-day retention, and reduced persisted payload data. Refs #185 Co-authored-by: OpenAI Codex <noreply@openai.com>
Remove the webhook database schema and in-process delivery metrics. The optional signed receiver now emits structured event logs with Svix IDs so external log analysis can deduplicate retries, order events, and calculate latency without ePDS retaining webhook data. Refs #185 Co-authored-by: OpenAI Codex <noreply@openai.com>
Ignore only missing temporary database directories during teardown instead of swallowing every filesystem error. Co-authored-by: OpenAI Codex <noreply@openai.com>
Include the verified email subject in structured delivery event logs so operators can distinguish messages during incident analysis. Refs #185 Co-authored-by: OpenAI Codex <noreply@openai.com>
Set Express trust-proxy configuration immediately after app creation so webhook rate-limit request IP handling is unambiguous. Co-authored-by: OpenAI Codex <noreply@openai.com>
Introduce Resend as a third-party email service in the release summary and state that ePDS continues to support other email providers. Co-authored-by: OpenAI Codex <noreply@openai.com>
Follow the auth-service import convention by placing external dependencies before the internal shared package. Co-authored-by: OpenAI Codex <noreply@openai.com>
Map Resend webhook payloads into provider-neutral delivery fields so future provider adapters can emit the same log schema. Centralize the Resend webhook path while leaving provider-specific verification in place. Refs #185 Co-authored-by: OpenAI Codex <noreply@openai.com>
Parse each webhook sender and log only events whose address exactly matches the instance SMTP_FROM. Unrelated account-wide events are acknowledged without exposing their payload, allowing multiple ePDS domains to share one Resend account when they use distinct sender addresses. Refs #185 Co-authored-by: OpenAI Codex <noreply@openai.com>
Resend models recipients as an array, which made Railway display the single ePDS recipient as recipients[0]. Webhook subjects also include the sign-in code and would expose it in logs.\n\nNormalize the recipient to the existing email field and redact only OTP tokens matching the configured length and charset while preserving the rest of the subject.\n\nFollow-up to #185.\n\nCo-authored-by: OpenAI <noreply@openai.com>
Use concise digit character classes so SonarCloud accepts the OTP subject sanitizer added for #185.\n\nCo-authored-by: OpenAI <noreply@openai.com>
SonarCloud reports intentional localhost, Docker, and Railway-private HTTP URLs as clear-text protocol vulnerabilities. Mark those exact lines with justified NOSONAR annotations because the traffic never crosses the public network.\n\nCo-authored-by: OpenAI <noreply@openai.com>
Closes #183. The per-send completion line previously carried only the recipient, so a slow-but-successful SMTP handoff was indistinguishable from a fast one and app logs could not be joined to Resend's per-message delivery events. Wrap every sendMail() in a timedSendMail() helper that measures the handoff, captures the result, and folds elapsedMs, messageId and smtpResponse into the existing success line — one enriched line per send across all four paths (client-branded, sign-in, welcome, backup). On failure it stamps elapsedMs onto the thrown error so the existing "failed to send OTP email" line carries the duration without adding a second failure line. The explicit-SMTP-timeouts part of #183 is intentionally deferred: it would change send behaviour (a slow-but-successful handshake could start failing) and the right values need to be chosen from real latency data, which the elapsedMs logging added here will itself provide. Tracked separately. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
feat(auth-service): log OTP send duration, messageId and SMTP response
Operators using Resend open tracking could see delivery outcomes but not whether the message's tracking pixel was fetched.\n\nAccept email.opened webhooks, normalize them to opened, and document the required tracking opt-in and reliability caveats. The event uses the existing sender filter and sanitized provider-neutral log fields.\n\nFollow-up to #185.\n\nCo-authored-by: OpenAI <noreply@openai.com>
…ooks Add optional Resend delivery event logging
Resend complaint, suppression, and scheduling events provide useful operational context but were rejected by the original delivery-focused allowlist. Known click and inbound events also caused pointless retries when subscribed accidentally.\n\nNormalize and log complained, suppressed, and scheduled events; acknowledge clicked and received events without logging their payloads. Document the expanded subscriptions and ratchet line coverage.\n\nCo-authored-by: OpenAI <noreply@openai.com>
…ional-events auth: expand Resend email event handling
prepare for release v0.7.0
Replace transition:generic with permission sets scopes
upgrade dev.certified.app to v0.7.0
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
|
🚅 Deployed to the ePDS-pr-210 environment in ePDS
|



Summary
Promote the tested
devdeployment toproduction, upgradingcertified.oneandauth.certified.onefrom v0.6.5 to v0.7.0.Release highlights
transition:generic.Full release notes: https://github.com/hypercerts-org/ePDS/releases/tag/ePDS%400.7.0
Verification
devpackage version:0.7.0https://dev.certified.app/health:0.7.0+904c871dhttps://auth.dev.certified.app/health:0.7.0+904c871d0.6.5+43bb4ff00.6.5+43bb4ff0