Summary

downloadLineMedia in extensions/line/src/download.ts wraps the LINE
Messaging API getMessageContent response in a for-await loop with no
read deadline. When the LINE CDN returns HTTP headers but then stalls the
body stream, the function blocks indefinitely. Because
extensions/line/src/bot-handlers.ts:467-482 awaits the result before
calling processMessage, the entire inbound dispatch hangs: no agent reply
is produced and the conversation goes silent.

This PR adds a per-chunk idle timeout (LINE_DOWNLOAD_IDLE_TIMEOUT_MS = 30_000) to cap both the headers-level fetch and each stream chunk read.
The ceiling matches the existing Telegram pattern
(extensions/telegram/src/bot/delivery.resolve-media.ts:161).
The timeout is idle (per-chunk), not overall, so legitimate slow-but-
progressing transfers continue.

Affected channel: LINE inbound media only.
Unaffected: Telegram, WhatsApp, MSTeams, Discord, Slack, Matrix,
all other channels. Pure-text LINE messages. LINE outbound path.

Behavior change

Implementation notes

• withChunkIdleTimeout<T>() wraps any AsyncIterable<T> so each next()
  call races against a setTimeout. On timeout, iterator.return() is
  called, which triggers Readable.destroy() for Node streams from
  @line/bot-sdk.
• @line/bot-sdk HTTPFetchClient.get does not accept AbortSignal, so
  the underlying fetch cannot be cancelled. On timeout, the function
  returns promptly but the background fetch may continue until TCP-level
  timeout. This is an acceptable trade-off; the caller proceeds without
  blocking.
• After the timeout wins the race, the still-pending next() and
  getMessageContent() promises are explicitly silenced
  (.then(noop, noop)) so a later rejection from the destroyed upstream
  cannot escape as an unhandledRejection on Node 22+.
• The caller error path at bot-handlers.ts:474-481 already handles
  arbitrary errors via String(err). The new error message includes
  "stalled", which routes to the runtime.error?.(danger(...)) branch
  (not the silent "exceeds limit" branch), so stalls are logged and
  dispatch continues without media.
• chunkTimeoutMs is an optional parameter so tests can use short values
  without touching the exported constant; no LINE config schema entry is
  added (out of scope for this PR; maintainer can request one if desired).
• Worst-case wall time before rejection is sequential
  ((1 headers race) + (N chunk races) of chunkTimeoutMs each), not a
  single 30 s shared deadline. With the default 30 s ceiling this is well
  inside LINE's 30 s webhook-ACK budget for the realistic single-stall
  case; deeply stalled CDNs with partial-progress flapping could exceed it
  but a follow-up overall-deadline option can be added if maintainers
  prefer.

Files changed

• extensions/line/src/download.ts (+113 / −6): adds
  LINE_DOWNLOAD_IDLE_TIMEOUT_MS, LineMediaDownloadTimeoutError,
  withChunkIdleTimeout(), wires options?.chunkTimeoutMs through both
  the headers-level race and the stream-consumption phase, and silences
  the orphaned upstream promises on timeout so they cannot become
  unhandledRejection.
• extensions/line/src/download.test.ts (+109 / −1): adds a
  chunk-idle timeout describe block with 6 focused regression tests.

Non-scope (deliberately separate PRs)

• WhatsApp downloadInboundMedia (extensions/whatsapp/src/inbound/media.ts) — same root pattern (no abort/timeout), separate PR.
• MSTeams resolveMSTeamsInboundMedia (extensions/msteams/src/monitor-handler/inbound-media.ts) — same root pattern, separate PR.
• Channel config knob for chunkTimeoutMs.
• Metadata-first dispatch (start processMessage while media hydrates in background) — would require restructuring bot-handlers.ts and is broader than the LINE narrow ceiling.

Real behavior proof

Current HEAD SHA: c10307cd7841cd3fe8df0ae92694f8b534153ba1. Proof captured against this exact HEAD; this body update is parser-label normalization only — no code, test, or config diff change.

Behavior addressed:

LINE inbound media download blocks indefinitely when the LINE CDN stalls the response body stream, preventing processMessage from being called and leaving the conversation silent. The contributor ask is to prove that, after this patch, a stalled LINE media boundary no longer blocks inbound dispatch — downloadLineMedia rejects within the configured ceiling, the existing catch path in bot-handlers.ts:467-499 logs the failure, buildLineMessageContext is still called, and processMessage is reached.

Real environment tested:

A local Node 22 process running the actual extension source via pnpm tsx, driving the real handleLineWebhookEvents entry point with a controlled stall installed at the @line/bot-sdk MessagingApiBlobClient.prototype.getMessageContent boundary. The production source — unmodified bot-handlers.ts dispatch path, unmodified downloadLineMedia, unmodified buildLineMessageContext, real openclaw/plugin-sdk/media-store, real ingress policy helpers — is exercised end-to-end. processMessage is the only spy. This is not a live LINE channel test; live LINE-CDN-side TCP behavior under partial-progress flapping is therefore not covered (see What was not tested).

Exact steps or command run after this patch:

node node_modules/.bin/tsx extensions/line/scratch/handler-stall-proof.mts body
node node_modules/.bin/tsx extensions/line/scratch/handler-stall-proof.mts headers
node node_modules/.bin/tsx extensions/line/scratch/handler-stall-proof.mts partial-stall
node node_modules/.bin/tsx extensions/line/scratch/handler-stall-proof.mts fast
node node_modules/.bin/tsx extensions/line/scratch/handler-stall-proof.mts slow-progress

The harness file extensions/line/scratch/handler-stall-proof.mts is not committed; it patches MessagingApiBlobClient.prototype.getMessageContent for the chosen scenario, then awaits the real handleLineWebhookEvents with a minimal LineHandlerContext whose processMessage is a JSON-emitting spy. Production default LINE_DOWNLOAD_IDLE_TIMEOUT_MS = 30_000 is used for all five scenarios.

Evidence after fix:

Redacted terminal capture from each pnpm tsx run, summarized into one row per scenario. Production default chunkTimeoutMs = 30_000 was used everywhere. runtime.error captures the exact log string the production catch path would emit.

Sample raw JSON output from the body scenario (redacted timestamps):

{
  "scenario": "body",
  "chunk_timeout_ms_default": 30000,
  "download_outcome": "timed-out",
  "process_message_called": true,
  "handler_settled": true,
  "handler_threw": false,
  "runtime_error_calls": [
    "line: failed to download media: LineMediaDownloadTimeoutError: LINE media download stalled: no data received for 30000ms"
  ],
  "unhandled_rejection_seen": false,
  "process_message_media_count": 0,
  "handler_elapsed_ms": 30029,
  "download_elapsed_ms": 30029,
  "download_error_name": "LineMediaDownloadTimeoutError"
}

Observed result after fix:

With the production default 30 s ceiling, the three stall scenarios (body, headers, partial-stall) each terminated in exactly one LineMediaDownloadTimeoutError at ~30 029 ms wall time, routed through the existing bot-handlers.ts:474-481 catch to runtime.error?.(danger(...)) (the "stalled" branch, not the silent "exceeds limit" branch). buildLineMessageContext was still invoked and processMessage was reached with zero media attachments. The two happy-path scenarios (fast, slow-progress) completed promptly and delivered one media attachment to processMessage. No unhandledRejection surfaced in any scenario after a 1 500 ms post-handler settle window — the orphan-rejection suppression in withChunkIdleTimeout and at the headers race both hold under real Node 22 event-loop scheduling.

What was not tested:

• A live LINE channel credential pair against the real LINE CDN with a real network-level stall. This would require a controlled-slow inbound media generator served by LINE's actual infrastructure plus a dedicated bot account; not feasible in this PR.
• WhatsApp and MSTeams unbounded-stall behavior (out of scope; separate PRs already enumerated in Non-scope).
• Production p99 percentiles for downloadLineMedia latency (no live traffic instrumented).
• The orphaned background fetch inside @line/bot-sdk HTTPFetchClient.get is acknowledged in Implementation notes but is not verified to settle within any specific TCP-level bound; that is a @line/bot-sdk SDK limitation, not introduced by this PR. The handler-level runtime proof above confirms the orphan does not surface as an unhandledRejection in the 1 500 ms window after handleMessageEvent returns.

Unit coverage

extensions/line/src/download.test.ts adds 6 focused regression tests under the chunk-idle timeout describe block. These are supplemental to the handler-level runtime proof above and validate the withChunkIdleTimeout wrapper in isolation against an @line/bot-sdk stub.

Suite results on the current HEAD: extensions/line/src/download.test.ts 12 passed; extensions/line 270 passed; pnpm check:changed green; pnpm format:check extensions/line/src/download.ts extensions/line/src/download.test.ts clean.