Skip to content

Consider explicit SMTP timeouts on the OTP transport (deferred from #183) #205

Description

@aspiers

Background

#183 proposed optionally setting explicit SMTP timeouts on the nodemailer transport so a hung handoff surfaces as an error on a known schedule, rather than inheriting nodemailer's defaults. PR #203 delivered the diagnostic-logging half of #183 (elapsedMs / messageId / smtpResponse) but deliberately dropped the timeout change, because it alters send behaviour and the values need justification from real data, not a guess.

Why deferred

Lowering connectionTimeout or greetingTimeout below the current defaults means a slow-but-successful handshake that succeeds today could start failing — which would make late/undelivered OTPs worse, the opposite of #183's goal. We have no measurement of Resend's real handshake latency, so any chosen value is a guess.

Verified nodemailer defaults

From nodemailer@6.10.1 (lib/smtp-connection/index.js), the constants actually used:

  • connectionTimeout120000 ms (2 min) — wait for TCP connection to establish
  • greetingTimeout30000 ms (30 s) — wait for SMTP greeting after connect (note: the docstring in that file says 10000, but the code uses the GREETING_TIMEOUT = 30 * 1000 constant)
  • socketTimeout600000 ms (10 min) — inactivity before disconnect (there is a default; it is not unbounded)

What to decide

Dependencies

Blocked on #203 being deployed long enough to collect an elapsedMs distribution.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions