Skip to content

Bound image attachment downloads so a stalled fetch cannot hang the action #1623

Closed

Description

@abhinavkr26104

Summary

downloadCommentImages awaits the signed image request with the global fetch API but does not provide an AbortSignal or timeout. A stalled GitHub attachment request can therefore keep context preparation waiting indefinitely before Claude is started.

Reproduction

  1. Trigger a workflow that processes an issue or pull request containing a GitHub user-attachment image.
  2. Intercept or mock the signed attachment URL so that the connection never resolves.
  3. Observe that downloadCommentImages remains pending and the action does not proceed to the Claude SDK or reach its normal error handling.

A deterministic unit test can reproduce this by mocking fetch to return a promise that never settles and asserting that the image-processing step rejects or skips the image after a bounded duration.

Expected behavior

A single unavailable or stalled image should be skipped or fail with a bounded, actionable error. The action should continue processing the remaining context or terminate according to a documented timeout.

Actual behavior

At src/github/utils/image-downloader.ts:241-251, the code directly awaits fetch(signedUrl) and then arrayBuffer() at line 251. Neither operation has a timeout or cancellation path. The surrounding try/catch handles rejection but cannot handle a promise that never settles.

Why this matters

GitHub-hosted attachment requests are external network operations. A transient CDN, proxy, or self-hosted-runner networking problem can turn one image into an unbounded action hang, consuming a runner and delaying or preventing all subsequent workflow steps.

Suggested fix

Use an AbortController with a configurable per-image timeout, apply the same bound while reading the response body, and log the URL plus timeout reason before skipping the image. Add tests for both a never-resolving fetch and a response body that stalls during arrayBuffer().

Related

This is separate from #702 and #1351, which concern image MIME detection, and from #1588, which concerns matching image URLs to signed asset URLs.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions