windkh/node-red-contrib-telegrambot V17.4.15

on GitHub

Fix sibling queue-wedge in out-node.js's processError non-retryable branch — issue #450 round 2.

V17.4.14 fixed one queue-wedge mechanism (the empty-content drop in hasContent). WJ4IoT's retest on V17.4.13 confirmed a sibling wedge on a different code path that V17.4.14 didn't cover.

Trigger

Any non-retryable bot error. WJ4IoT's deterministic repro: a Markdown-mode message containing an unescaped _ — Telegram rejects with ETELEGRAM: 400 Bad Request: can't parse entities. Sequence:

1. bot.sendMessage(..., { parse_mode: 'Markdown' }) rejects
2. .catch(processError) runs
3. processError checks 429 / ENOTFOUND / ECONNRESET — none match → retry = false
4. Non-retry branch: logs node.error(), invokes nodeDone() if present
5. processNext(chatId) is never called → processing[chatId] stays true forever
6. Every subsequent send to that chat queues but never starts

Same wedge symptom as V17.4.14's empty-content drop, different trigger. WJ4IoT's workaround (regex-strip Markdown special chars from content) prevented the trigger but didn't fix the underlying bug.

Fix

Add node.queueManager.processNext(chatId) after the non-retry branch's logging. The retry branch (429 / ENOTFOUND / ECONNRESET) uses repeatProcessMessage which re-runs the same message; a successful retry's processResult then advances naturally — so only the give-up path needed the explicit advance.

Tests

1 new mocha regression case: bot stub whose first sendMessage rejects with the canonical Markdown-parse-error string and subsequent calls succeed. Pre-fix the second send wouldn't reach the bot. Post-fix both calls land and processing[123] is false. 242 passing.

V18 status

Same fix landed on the migration/ntba-v1 branch in 50194c2; V18.0.0-beta.1 carries it too.