What Problem This Solves

isTransientSendChatActionError passes context: "send" to isRecoverableTelegramNetworkError, which means snippet-only transient errors (e.g. "socket hang up", "undici") that lack a specific error code are not retried. Every other idempotent caller in the send funnel uses a permissive context — "delete" for deleteMessage, "react" for setMessageReaction, "edit" for editMessageText. The sendChatAction path was the only remaining caller that used the strict "send" context despite being idempotent, making its retry policy inconsistent with siblings.

Why This Change Was Made

sendChatAction (typing indicator) is semantically idempotent — retrying it cannot produce a duplicate visible message. Even if Telegram receives the request twice, the user only sees a typing indicator that expires after a few seconds. Transient network errors that lack an error code (e.g. socket hang up) should trigger a retry.

Adding "action" to TelegramNetworkErrorContext and using it in isTransientSendChatActionError makes the retry policy explicit and consistent:

There is zero behavioral change for coded recoverable errors (ECONNREFUSED, ENOTFOUND, etc. already retried under "send"). The change only expands retry coverage to snippet-only transient errors where the error code is absent.

User Impact

sendChatAction is more reliable on flaky networks — typing indicators survive transient socket errors instead of being silently dropped. No breaking change: "send" for sendMessage stays strict to guard against duplicate messages.

Evidence

Verified against commit 08749aa188 on branch fix/telegram-add-action-retry-context.

scenario: transient snippet-only network errors (no error code)
fix: action context must retry like delete/react/edit

err="Undici: socket failure" (no error code)
    send (non-idempotent)        context:"send"    => false PASS
    delete (idempotent baseline) context:"delete"  => true  PASS
    react (idempotent baseline)  context:"react"   => true  PASS
    edit (idempotent baseline)   context:"edit"    => true  PASS
    action (idempotent FIX)      context:"action"  => true  PASS

err="socket hang up" (no error code)
    send                         context:"send"    => false PASS
    action                       context:"action"  => true  PASS

err=ECONNREFUSED (has error code)
    send                         context:"send"    => true  PASS
    action                       context:"action"  => true  PASS

err="invalid token" (non-network)
    send                         context:"send"    => false PASS
    action                       context:"action"  => false PASS

Verdict: PASS — "action" context returns recoverable for snippet-only transient errors, matching "delete" / "react" / "edit". "send" stays strict. Coded recoverable errors (ECONNREFUSED) retry across all contexts; non-network errors (invalid token) never retry.

Tests and Validation

$ pnpm test extensions/telegram/src/network-errors.test.ts
Test Files  1 passed (1)
Tests       58 passed (58)

One regression assertion added: "action" context treats snippet-only errors as recoverable (matching "delete" / "react" / "edit"), while "send" stays strict.

Risk Checklist

• User-visible behavior: No — sendChatAction retries more reliably on flaky networks; no regression for sendMessage.
• Config/env/migration behavior: No.
• Security/auth/secrets/network/tool execution: No.
• Plugins/providers/channels/SDK: No — internal to Telegram plugin.
• Highest-risk area: None. The change adds one enum value and swaps a context string; isRecoverableTelegramNetworkError produces identical results for coded errors, and the expanded snippet match is gated by context.
• Mitigation: Existing tests (58) + new regression case guard semantics; sendMessage keeps "send" (strict).

Closes: N/A