Skip to content

fix(notifications): stop email dispatch from logging one error per notification - #841

Merged
github-actions[bot] merged 1 commit into
mainfrom
fix/email-dispatch-log-flood
Aug 29, 2026
Merged

fix(notifications): stop email dispatch from logging one error per notification#841
github-actions[bot] merged 1 commit into
mainfrom
fix/email-dispatch-log-flood

Conversation

@catomean

Copy link
Copy Markdown
Collaborator

Summary

  • RESEND_API_KEY is unset in production, which is a known/pending config gap — not something this PR fixes.
  • Without it, every dispatched notification threw inside sendEmailNotification(), and the dispatcher logged a fresh logger.error per occurrence: 56 identical "RESEND_API_KEY is not set" errors in 24h, drowning any real email failure in the same log.
  • The dispatcher already has isEmailConfigured() available but wasn't calling it before attempting a send. Added the guard: warns once per process instead of once per notification, then returns early.

This does not configure email — sending real notification emails still needs a RESEND_API_KEY on the box, which is a separate decision for the account owner.

Test plan

  • tsc --noEmit clean
  • Full pre-push suite (typecheck, route audit, 2581 unit tests) passed

🤖 Generated with Claude Code

https://claude.ai/code/session_01Y9rKLxddothnXEtY6KDziN

…tification

isEmailConfigured() exists specifically so callers can short-circuit before
attempting a send — this dispatcher wasn't using it. Every dispatched
notification for an email-enabled type went straight to getEmailClient(),
which throws 'RESEND_API_KEY is not set', caught and logged as a fresh
error every time.

Found via a fleet-wide log audit: 56 identical errors in 24h, one per
queued notification. The condition (no key deployed) is static, not
per-notification — it only needs saying once. Now warns once per process
via the same "warn once" pattern getEmailClient() already uses for its own
placeholder-key case, then returns cleanly.

This does not configure email — RESEND_API_KEY is still absent from
production, which is a config/product decision (provide a key, or decide
notifications don't need email) for someone with the account, not something
to fix by adding a credential blind. This fixes the failure MODE: loud once,
not flooding forever.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y9rKLxddothnXEtY6KDziN
@github-actions
github-actions Bot merged commit 58d98b8 into main Aug 29, 2026
6 checks passed
@github-actions
github-actions Bot deleted the fix/email-dispatch-log-flood branch August 29, 2026 09:39
catomean added a commit that referenced this pull request Aug 29, 2026
…tage (#844)

Peer review on the log-flood fix (PR #841) flagged that "email notifications
are disabled" reads as a benign default, not the outage it is — a quiet
single warning is easy to miss, and this removes the only signal that
notifications are being dropped. Reworded to say plainly that emails are
being discarded and name the provider, so one grep hit is enough to act on.

Co-authored-by: Georgy Butaev <41178744+g-but@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant