fix(mail): SMTP connect timeout + circuit-breaker so a down mail server can't stall the cron#236
Conversation
…er can't stall the cron Observed on a real instance whose SMTP host was unreachable: the automatic-notifications cron logged a wall of "Could not connect to SMTP host" — one full 3-attempt retry cycle (with 1s sleeps) for every overdue-loan recipient. Two robustness gaps: - The PHPMailer path never set Timeout, so it used PHPMailer's 300s default: an SMTP host that accepts the TCP connection but then stalls would block the run for 5 minutes per email. Cap it at 10s (configurable via mail.smtp.timeout); the raw-socket path already used 10s. - No circuit-breaker: every recipient got the full retry cycle even though they all fail the same way when the server is down. Add Mailer::isSmtpReachable() — a single short TCP probe (4s), cached per request, logged once — and short-circuit sendWithRetry on it. The batch still runs (loans still marked overdue, in-app notifications still created); only the email attempts become cheap no-ops when the server is unreachable. Verified: probe returns false in 0.00s on connection-refused and ~4s on an unroutable host (never the 300s default). php -l + PHPStan L5 clean.
|
Warning Review limit reached
Next review available in: 50 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ 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 |
1 participant
Observed on a real instance whose SMTP host was unreachable: the
automatic-notificationscron logged a wall ofCould not connect to SMTP host— a full 3-attempt retry cycle (with 1s sleeps) for every overdue-loan recipient. Two robustness gaps:Timeouton the PHPMailer path → PHPMailer's 300s default. An SMTP host that accepts the TCP connection but then stalls would block the run for 5 minutes per email. Capped at 10s (configurable viamail.smtp.timeout); the raw-socket path already used 10s.Mailer::isSmtpReachable()— a single short TCP probe (4s), cached per request, logged once — and short-circuitsendWithRetryon it, so a down SMTP costs one probe instead of N × 3 connection timeouts.The batch still runs (loans still marked overdue, in-app notifications still created); only the email attempts become cheap no-ops when the server is unreachable.
Verified
Probe returns
falsein 0.00s on connection-refused and ~4s on an unroutable host (never the 300s default). php -l + PHPStan L5 clean.Note: this is defensive robustness — the reported instance's actual problem is its own SMTP config being unreachable, which no code change fixes.