Skip to content

fix: carry the API error body of a failed streaming request - #1055

Open
vdusek wants to merge 3 commits into
v3from
fix/streaming-error-body
Open

fix: carry the API error body of a failed streaming request#1055
vdusek wants to merge 3 commits into
v3from
fix/streaming-error-body

Conversation

@vdusek

@vdusek vdusek commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

Follow-up to #1041.

A failed request with responseType: 'stream' (LogClient.stream(), getRecord({ stream: true })) handed an unread IncomingMessage to ApifyApiError. JSON.stringify threw on its circular references, so the message read Unexpected error: [object Object] and the API's type, message and data were lost.

HttpClient now reads a streamed error body into a buffer before building the error, as the Python client does, using concatStreamToBuffer from @apify/utilities. A read that fails mid-body is swallowed: a raw socket error carries no status code, which would break getRecord({ stream: true }) resolving to undefined on a 404. ApifyApiError decodes the buffer once and keeps a non-JSON body as text, so an HTML error page from a proxy is readable instead of a dump of byte values. That last part also improves downloadItems() and getRecord({ buffer: true }) errors.

Known limitation, left as a follow-up: the body read sits outside the axios timeout, because axios settles a stream response at its headers. The agent's socket idle timeout bounds it, measured at 2043 ms under a 2 s client timeout, and maxContentLength: -1 leaves it without a size cap. Tightening either needs a separate error-body budget.

Closes #1043

✍️ Drafted by Claude Code

@vdusek vdusek added the t-tooling Issues with this label are in the ownership of the tooling team. label Sep 10, 2026
@vdusek vdusek self-assigned this Sep 10, 2026
@github-actions

github-actions Bot commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

⚠️ There are broken links in the documentation.

See more at https://github.com/apify/apify-client-js/actions/runs/34492190815#summary-102921472000

@vdusek
vdusek requested a review from barjin September 10, 2026 09:20
@vdusek
vdusek marked this pull request as ready for review September 10, 2026 09:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

t-tooling Issues with this label are in the ownership of the tooling team.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants