V17.4.1 — quiet the fatal-error log noise from V17.4.0
Patch release on top of V17.4.0 carrying a single fix surfaced by @Bobo-amg's V17.4.0 retest of #411.
The fix
During a network outage to Telegram's API (e.g. ETIMEDOUT 149.154.166.110:443) the bot library emits 'error' many times in rapid succession — one per pending request that fails. The V17.4.0 auto-restart's single-flight correctly collapsed the restart attempts to one per burst, but the warn line above the scheduleRestart call was logged unconditionally. Result: "pages and pages" of identical Bot error: ... warnings even though only one restart was actually being scheduled.
V17.4.1 gates the warn on !self.restartTimer:
- The first error of a burst still logs (operator gets the diagnostic).
- Subsequent errors during the same outage stay silent —
scheduleRestarthas setrestartTimerand the warn check sees it. - Once the backoff fires and clears the timer, the next genuinely-new fatal logs again.
The scheduleRestart "will restart in Xms" warn (which has always been single-flight) plus the surviving first "Bot error" line together still describe the situation; the suppressed copies added no information.
No behaviour change otherwise
The auto-restart itself is unchanged — same backoff, same single-flight, same surrender-after-8 cap. If your bot was recovering between incidents on V17.4.0 it will keep doing so on V17.4.1, just with a much quieter log.
Underlying connectivity issues are still on the operator
If you're seeing repeated connect ETIMEDOUT 149.154.166.110:443 in your trace, that's a TCP-level failure reaching Telegram's API and the plugin can't fix it. Things worth checking on the host:
- DNS for
api.telegram.org(dig +short api.telegram.org) — some hosts work better with1.1.1.1/8.8.8.8than ISP defaults. - IPv4 vs IPv6 race — the bot node has an
Address familyconfig field; setting it to4forces IPv4-only, which eliminates theAggregateError [ETIMEDOUT]shape if your IPv6 path is flaky but IPv4 is OK. mtr -T -P 443 149.154.166.110from the affected host during an incident — reveals if a specific hop is dropping.
Test coverage
One new mocha case in test/nodes/bot-node-restart.test.js simulates a 3-event burst and asserts exactly one "Bot error:" line is emitted (carrying the first event's message). 205 tests pass.