Repository navigation
fix(email): don't send from auth@undefined and report when email isn't configured - #3003
Conversation
… and surface send failures Self-hosts without RESEND_FROM_DOMAIN sent from auth@undefined, which Resend rejects, while the UI still said a code was sent. Email is now treated as configured only when the API key and sender are both available, login codes are logged otherwise, the verify screen says email is not configured, explicit fromOverride senders keep working without a default domain, and invite APIs report not_configured instead of accepted.
|
@07rjain is attempting to deploy a commit to the Cap Software Inc Team on Vercel. A member of the Team first needs to authorize it. |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| {emailDeliveryConfigured ? ( | ||
| <p className="text-sm text-gray-10"> | ||
| We sent a 6-digit code to {normalizedEmail} | ||
| </p> | ||
| ) : ( | ||
| <p className="text-sm text-gray-10"> | ||
| Email (Resend) is not configured on this server. The 6-digit code | ||
| for {normalizedEmail} was printed to the server logs. Ask your | ||
| administrator, or set RESEND_API_KEY and RESEND_FROM_DOMAIN. |
There was a problem hiding this comment.
The new emailDeliveryConfigured flag fixes the page text, but the resend toast still says “A new code has been sent to your email!” when email is disabled. Requesting another code only prints it to the server logs. Use the flag in handleResend.onSuccess too, so users are not sent back to their inbox.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/web/app/(org)/verify-otp/form.tsx
Line: 176-184
Comment:
**Resend still promises an email**
The new `emailDeliveryConfigured` flag fixes the page text, but the resend toast still says “A new code has been sent to your email!” when email is disabled. Requesting another code only prints it to the server logs. Use the flag in `handleResend.onSuccess` too, so users are not sent back to their inbox.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.| const error = result.value?.error; | ||
| return Boolean(error && error.name !== "email_not_configured"); |
There was a problem hiding this comment.
Excluding email_not_configured from failedInvites keeps the invite links usable, but it also leaves failedEmails empty. InviteDialog then shows “Invites sent successfully” without warning that no email was sent. Return a separate delivery status and show the skipped-email notice without deleting the invite records.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/web/actions/organization/send-invites.ts
Line: 190-191
Comment:
**Skipped invites look sent**
Excluding `email_not_configured` from `failedInvites` keeps the invite links usable, but it also leaves `failedEmails` empty. `InviteDialog` then shows “Invites sent successfully” without warning that no email was sent. Return a separate delivery status and show the skipped-email notice without deleting the invite records.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
|
Thanks @07rjain for splitting this out of #2580, the
Once that's pushed, it needs to reach Greptile 5/5 with green CI before we can merge. You can mention @greptileai in a comment to get a re-review after pushing. Thanks! |
|
Agreed—these are valid follow-ups. The resend toast should reflect The missing-key behavior also needs to retain the production failure for Cap Cloud ( These changes need to be pushed and CI rerun before merge. Once the updated revision is available, it can be re-reviewed. |
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Avoid claiming invitations were sent in mixed skipped and failed batches. Propagate returned support email errors to the existing failure handler. Cover resend destinations, invitation notices and support provider errors with regression tests.
|
@greptileai please re-review the latest changes on commit 7543750. The branch includes current main and fixes for the resend toast, skipped-invite notices, mixed delivery results, Cap Cloud missing-email behavior, and support delivery errors. The displayed 4/5 review predates these fixes. Validation: 97 focused tests and repository typecheck pass. |
| if ( | ||
| process.env.NODE_ENV === "production" && | ||
| buildEnv.NEXT_PUBLIC_IS_CAP | ||
| ) { | ||
| throw new Error(emailStatus.reason); |
There was a problem hiding this comment.
Production self-hosts with NEXT_PUBLIC_IS_CAP="false" and no Resend key now fail email sign-in instead of printing a code. NEXT_PUBLIC_IS_CAP is an optional string, so "false" passes this new Cap Cloud check. The same check in sendMobileEmailCode blocks mobile sign-in too.
Compare the flag with "true" in both places so self-hosts keep the promised server-log fallback.
Prompt To Fix With AI
This is a comment left during a code review.
Path: packages/database/auth/auth-options.ts
Line: 264-268
Comment:
**Self-hosted sign-in gets blocked**
Production self-hosts with `NEXT_PUBLIC_IS_CAP="false"` and no Resend key now fail email sign-in instead of printing a code. `NEXT_PUBLIC_IS_CAP` is an optional string, so `"false"` passes this new Cap Cloud check. The same check in `sendMobileEmailCode` blocks mobile sign-in too.
Compare the flag with `"true"` in both places so self-hosts keep the promised server-log fallback.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Treat NEXT_PUBLIC_IS_CAP=false as self-hosted in web and mobile sign-in, email configuration, sender selection and marketing suppression. Cover unset, empty, false and true values while preserving production Cap Cloud email failures.
|
@greptileai please re-review the latest changes on commit 22a860e. The self-hosted sign-in P1 is fixed: only NEXT_PUBLIC_IS_CAP="true" enables Cap Cloud behavior in web/mobile sign-in and email configuration. Explicit "false" keeps login-code logging, the configured self-host sender, and marketing suppression. Five regressions reproduced the issue before the fix; all 107 focused tests, repository typecheck and scoped Biome now pass. |
Split out of #2580 (email delivery status).
Self-hosted installations with a Resend key but no sender domain could send from
auth@undefinedwhile the UI claimed success. Email configuration and provider errors are now reported explicitly; an explicit sender override still works without a default domain.skippedEmailsseparately fromfailedEmails. Skipped invite records remain usable, and the dialog tells admins the invites were created but not emailed and to share their links. Failed delivery warnings do not claim emails were sent, including batches with both skipped and failed messages. Only genuine delivery failures are cleaned up.not_configureddelivery status. Mobile email sign-in uses the shared configuration check.getEmailDeliveryStatusand cover unconfigured self-hosted and hosted behavior. The vacuous sender test is removed.The branch includes current main at
3614bdb692af7317c30c0ad7afaa496a6974c2eb, integrating 174 upstream commits without conflicts.Validation: 107 focused tests passed across nine suites covering configuration/senders, mobile email sessions, authentication, NextAuth routes, invite record retention and cleanup, actual resend/invitation UI interactions, account deletion notifications, and Messenger support delivery and failure handling. The new mixed-batch UI regression and both support provider-error regressions failed before their fixes and passed afterward. Repository
bun run typecheck, scoped Biome checks and self-hosting guide MDX compilation passed. No real emails were sent during validation.All original reviewer findings and the follow-up P1 about
NEXT_PUBLIC_IS_CAP="false"are addressed. Only"true"enables Cap Cloud email behavior; unset, empty and"false"values retain self-hosted login-code logging, sender-domain requirements and marketing suppression. Five explicit-false regressions failed before the fix and pass afterward. Review of this head and maintainer approval for fork CI remain pending.
The PR appears safe to merge; all three previous findings are addressed and no new blocking issue was found.Summary
The PR reports missing email configuration and provider errors instead of claiming delivery succeeded.
Reviews (3) · Last reviewed commit: "fix(email): require an explicit Cap Clou..." · Reviewed by Greptile