Greptile Summary

This PR extends the existing sendChatAction 401-backoff circuit-breaker to also handle transient network errors (ECONNRESET, ETIMEDOUT, fetch failures, etc.), treating sendChatAction as best-effort by swallowing those errors rather than propagating them, and suspending after a configurable number of consecutive network failures.

• The dual-counter design (consecutive401Failures / consecutiveTransientFailures) with mutual reset on success and on the opposing error type is correct; only one counter can be non-zero at a time, so totalFailures correctly drives the shared backoff.
• isTransientNetworkError uses a broad lower.includes("network request") fragment that could accidentally classify an API-level error (e.g. "network request returned status 500") as transient and silently swallow it — narrowing to lower.includes("network request for") would match the actual SDK pattern without the wider risk.
• The backoff log message was simplified to (failure N), dropping the N/max indicator that was useful for operators monitoring 401-rate logs.
• Test coverage for the new paths is thorough (4 new tests, existing test updated).

Confidence Score: 5/5

Safe to merge — logic is correct and well-tested; remaining findings are P2 style improvements.

All findings are P2 (broad substring match, missing max in log message). No correctness, data-integrity, or reliability issues found. The dual-counter backoff logic is sound and all new behaviour is covered by tests.

sendchataction-401-backoff.ts — minor: tighten the 'network request' substring predicate and restore the N/max indicator in the backoff log.

This is a comment left during a code review.
Path: extensions/telegram/src/sendchataction-401-backoff.ts
Line: 72

Comment:
**Overly broad "network request" substring match**

`lower.includes("network request")` is a very generic fragment. An API error like `"network request returned status 500"` or `"rate-limited: too many network requests"` would match this predicate and be silently swallowed as a transient error. The other patterns (`econnreset`, `etimedout`, `fetch failed`, `socket hang up`) are specific low-level I/O error codes, but this one could absorb HTTP-level failures from Telegram's API itself.

Consider tightening the match to the actual Node.js fetch/undici error message format:
```suggestion
    lower.includes("network request for") ||
```
This still catches the documented Telegram bot SDK pattern (`"Network request for 'sendChatAction' failed!"`) without matching unrelated strings containing "network request".

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/telegram/src/sendchataction-401-backoff.ts
Line: 119-121

Comment:
**Backoff log no longer shows suspension threshold**

The previous message included `(failure ${consecutive401Failures}/${maxConsecutive401})`, giving operators an at-a-glance view of how many more failures remain before suspension. The new unified message `(failure ${totalFailures})` drops the max, which makes it harder to triage a stream of 401 backoff logs in production.

Consider restoring context-sensitive max information:
```suggestion
      logger(
        `sendChatAction backoff: waiting ${backoffMs}ms before retry ` +
          `(failure ${totalFailures}/${consecutive401Failures > 0 ? maxConsecutive401 : maxConsecutiveTransient})`,
      );
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(telegram): add backoff for transient..." | Re-trigger Greptile}

Resolved both review findings:

1. Tightened network error match — narrowed "network request" to "network request for" to avoid accidentally matching HTTP-level errors like "network request returned status 500".
2. Restored failure threshold in log — backoff message now shows (failure N/max) with context-sensitive max based on whether the current failures are 401 or transient.

See commit f8de59f.

Closing this as duplicate or superseded after Codex automated review.

Close PR #55838 as superseded. Current main no longer matches the original retry-spam failure mode because Telegram typing goes through the shared typing lifecycle and stops the keepalive loop after consecutive start failures. The narrower handler-level transient cooldown work is now tracked by the newer open PR #55886, which came from the #55811 discussion and covers the same Telegram sendChatAction surface with review follow-ups.

Best possible solution:

Close #55838 as superseded, keep the shipped shared typing breaker behavior on main, and route any remaining Telegram sendChatAction transient cooldown work through the newer canonical PR #55886.

What I checked:

• Current handler is still 401-only on main: At current main 7e376e5, createTelegramSendChatActionHandler only accepts maxConsecutive401, applies backoff for consecutive401Failures, and rethrows after the 401 branch; searches found no maxConsecutiveTransient/consecutiveTransient implementation on main. (extensions/telegram/src/sendchataction-401-backoff.ts:46, 7e376e5aba32)
• Current main mitigates the linked retry-spam symptom: Telegram dispatch passes sendTyping into createChannelReplyPipeline, which builds createTypingCallbacks. That lifecycle defaults maxConsecutiveFailures to 2 and stops the keepalive loop when createTypingStartGuard trips after consecutive start failures. (src/channels/typing.ts:23, 7e376e5aba32)
• Regression coverage exists for the shared breaker: The shared typing test advances multiple keepalive windows after repeated start failures and asserts only two start attempts occur, locking in the behavior that prevents minute-long 3-second retry spam. (src/channels/typing.test.ts:110, 7e376e5aba32)
• Related issue discussion supersedes this PR: Issue Telegram sendChatAction retry spam during transient failures #55811 comments show Boulea7 opened fix(telegram): cool down transient sendChatAction failures #55886 as the minimal handler-focused PR after local verification; a later maintainer comment closed Telegram sendChatAction retry spam during transient failures #55811 as not reproducible on current main because the shared typing lifecycle now stops the retry loop.
• Canonical remaining work is PR fix(telegram): cool down transient sendChatAction failures #55886: PR fix(telegram): cool down transient sendChatAction failures #55886 is open, targets the same Telegram sendChatAction transient failure surface, and its body/files cover network, 429, and temporary 5xx cooldown behavior. Its comments show follow-ups for structured 429 detection and preserving rejection so the shared typing guard can count failures.

So I’m closing this here and keeping the remaining discussion on the canonical linked item.

Codex Review notes: model gpt-5.5, reasoning high; reviewed against 7e376e5aba32.