Conversation
…2851) Add RESEND_FROM_TRUST_PORTAL so Trust Portal access and NDA emails can ship from a brand-specific sender (e.g., noreply@mail.trust.inc), distinct from the generic system sender. triggerEmail() gets a new `trustPortal: true` flag that resolves the new env var, with graceful fallback to RESEND_FROM_SYSTEM so existing deploys keep working until the env var is set in Trigger.dev / Render. TrustEmailService (NDA signing, access granted, access reclaim, access request notification) now uses `trustPortal: true`. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Previously triggerEmail() resolved the FROM address on the API host
(Render) by reading RESEND_FROM_* env vars and passing the literal
address to the Trigger.dev task. This forced sender env vars to be
duplicated across Render and Trigger.dev environments.
Move resolution into the send-email task:
- triggerEmail() now passes a channel ('marketing' | 'system' |
'trustPortal' | 'default') instead of a resolved address
- send-email.ts reads RESEND_FROM_* on Trigger.dev's side and picks
the right sender via a switch on channel
- params.from is still honored as an explicit override
- Unknown/missing channel falls through to the outer chain, preserving
prior behavior for direct task callers (e.g., EmailController)
Public API of triggerEmail() is unchanged — callers still pass the
same marketing/system/trustPortal boolean flags. No call sites need
to change.
Net effect: Render no longer needs RESEND_FROM_* vars to be set —
Trigger.dev becomes the single source of truth for email sender
configuration.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Follow-up to the channel refactor — the internal /v1/internal/email/send
endpoint was still reading RESEND_FROM_SYSTEM/RESEND_FROM_DEFAULT on the
API host to compute the from address. With the rest of the pipeline now
resolving on Trigger.dev, this controller is the last Render-side reader
of those env vars in the email flow.
Pass channel ('system' | 'default') based on dto.system instead. The
Trigger.dev task resolves the env var on its side. dto.from is still
honored as an explicit override via params.from.
After this lands, Render genuinely doesn't need any RESEND_FROM_* var
for the single-email path. send-batch-email still reads them on Render
and is out of scope here.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* refactor(email): move FROM resolution into Trigger.dev task
Previously triggerEmail() resolved the FROM address on the API host
(Render) by reading RESEND_FROM_* env vars and passing the literal
address to the Trigger.dev task. This forced sender env vars to be
duplicated across Render and Trigger.dev environments.
Move resolution into the send-email task:
- triggerEmail() now passes a channel ('marketing' | 'system' |
'trustPortal' | 'default') instead of a resolved address
- send-email.ts reads RESEND_FROM_* on Trigger.dev's side and picks
the right sender via a switch on channel
- params.from is still honored as an explicit override
- Unknown/missing channel falls through to the outer chain, preserving
prior behavior for direct task callers (e.g., EmailController)
Public API of triggerEmail() is unchanged — callers still pass the
same marketing/system/trustPortal boolean flags. No call sites need
to change.
Net effect: Render no longer needs RESEND_FROM_* vars to be set —
Trigger.dev becomes the single source of truth for email sender
configuration.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* refactor(email): emailcontroller send uses channel not env reads
Follow-up to the channel refactor — the internal /v1/internal/email/send
endpoint was still reading RESEND_FROM_SYSTEM/RESEND_FROM_DEFAULT on the
API host to compute the from address. With the rest of the pipeline now
resolving on Trigger.dev, this controller is the last Render-side reader
of those env vars in the email flow.
Pass channel ('system' | 'default') based on dto.system instead. The
Trigger.dev task resolves the env var on its side. dto.from is still
honored as an explicit override via params.from.
After this lands, Render genuinely doesn't need any RESEND_FROM_* var
for the single-email path. send-batch-email still reads them on Render
and is out of scope here.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claudio Fuentes <claudio@trycomp.ai>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
|
🎉 This PR is included in version 3.55.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an automated pull request to release the candidate branch into production, which will trigger a deployment.
It was created by the [Production PR] action.
Summary by cubic
Adds a dedicated sender for Trust Portal emails via
RESEND_FROM_TRUST_PORTALand moves FROM resolution into the Trigger.devsend-emailtask using a channel. The API now passeschannel(or honors afromoverride), so Render no longer readsRESEND_FROM_*for single-email sends.New Features
trustPortalflag totriggerEmail()to selectRESEND_FROM_TRUST_PORTAL(falls back toRESEND_FROM_SYSTEM).trustPortal: true.RESEND_FROM_TRUST_PORTALto.env.examplefiles.Migration
RESEND_FROM_TRUST_PORTALin Trigger.dev. Render no longer needsRESEND_FROM_*for the single-email path.Written for commit d028747. Summary will update on new commits.