Patch release: fixes a crash that could take down the whole Node-RED process during a network outage (#503). No new nodes, no changed options, no flow migration.
Do I have to do anything?
No — upgrade normally. There is no configuration change.
What was wrong
If your bot lost its connection to Telegram (EFATAL: fetch failed in the log, usually a DNS/IPv6 or general network problem), Node-RED could die outright rather than ride the outage out:
[red] Uncaught Exception:
TypeError: Cannot read properties of null (reading 'stopPolling')
at TelegramBotEx.<anonymous> (.../telegrambot/nodes/bot-node.js:550:42)
at TelegramBotPolling._emitError (.../node-telegram-bot-api/dist/polling.cjs:82:18)
nodered.service: Main process exited, code=exited, status=1/FAILURE
The polling_error handler is attached to one specific bot instance, but it acted on whichever instance was currently installed on the config node. Those two drift apart during recovery: the automatic restart retires the old bot and builds a new one, while the retired bot's cancelled getUpdates call settles a moment later and reports its error to the handler still attached to it. Handling that stale report dereferenced a bot that no longer existed. Because the handler runs from a promise rejection inside an event emitter, nothing could catch the error — so it killed the process instead of being logged.
Most likely to bite on a Full Deploy while the network was already flapping, which is when the deploy's shutdown, the 3 s polling retry and the 3 s restart back-off all land on top of each other.
The same cause had a second, quieter effect: when a replacement bot had already been built, the stale report stopped and restarted the new bot's polling and fed its failure counters — so the recovery mechanism was working against itself and dragging out the very outage it was supposed to fix. If you have seen bots take a long time to come back after a network blip, this is a likely contributor.
The fix
A polling error is now handled only while the bot instance that reported it is still the installed one; reports from a retired instance are ignored (they are logged if you enable verbose logging on the bot config node). The timers on that path were only checking that a bot existed, which a replacement satisfies — they now check that it is the same bot, so a timer armed for the old bot can no longer disturb the new one.
Note on EFATAL: fetch failed
This release stops that error from crashing Node-RED, but it does not stop the error itself — the node now absorbs it and keeps retrying with exponential back-off up to 60 s. If you see it repeatedly, it is a connectivity problem worth chasing on the host. A common cause on Raspberry Pi is IPv6: try setting Address family to IPv4 in the bot config node.