fix(cron): say which thing is actually broken - #82
Merged
Conversation
/api/cron/emails returned {"error":"Database unavailable"} while the database
was fine — psql connects with the app's own DATABASE_URL and the schema has 25
tables. The route hardcoded one of the workflow's two possible errors, so an
email-configuration failure was reported as a database failure.
The log line beside it made the same mistake in the other direction: it said
"RESEND_API_KEY not configured" while the key was present, 36 characters and
correctly prefixed re_. isEmailConfigured() is false for TWO reasons, and the
second one — a sandbox sender, which is exactly the case the guard was written
for — announced the first.
Both now name the reason that applies. The guard itself is correct and stays:
refusing to mark a queue sent when the sender reaches nobody is the whole point
of it.
The underlying condition is unchanged and is an operator decision: RESEND_FROM
is a sandbox address, so no patient email can be delivered until a verified
domain is set.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UvjGNAS9CMfEGNW26tUR4P
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.
/api/cron/emailsreturned{"error":"Database unavailable"}while the database was fine —psqlconnects with the app's ownDATABASE_URLand the schema has 25 tables.Two messages, both naming the wrong cause for the same failure:
route.ts"Database unavailable"cron-emails.ts"RESEND_API_KEY not configured"re_isEmailConfigured()is false for two reasons, and the log only ever announced one of them. The reason that actually applied is the second: a sandbox sender — precisely the case the guard was written for.The guard is correct and stays. Its own comment says it best: "It looks configured — the key is set, the API returns no transport error — but delivers to nobody… This shipped to production once; the guard ends the class." Refusing to mark a queue sent when the sender reaches nobody is the whole point.
What changes is only that each message names the reason that applies. Chasing Postgres for an hour because the error said "database" is the cost of a message that guesses.
Unchanged, and an operator decision:
RESEND_FROMis a sandbox address, so no patient email can be delivered until a verified domain is configured in Resend. The queue is correctly left pending rather than falsely marked sent.🤖 Generated with Claude Code
https://claude.ai/code/session_01UvjGNAS9CMfEGNW26tUR4P