PR Custody

fix(core): drop manual Content-Length in S3 upload PUT for compat with strict undici dispatcher (refs #3548)

@ThrouMisichecks n/achecks…fix/file-upload-content-length-header-next → next1 files · +5 −1review: @jkomynoupdated 1d ago

GitHub

▸Description· 2 comments · 1 noise

Summary

Remove the manual Content-Length header from the presigned-URL PUT in uploadFileToS3. Node.js's built-in fetch (undici) computes Content-Length from the request body itself and rejects any user-supplied value with InvalidArgumentError: invalid content-length header (UND_ERR_INVALID_ARG), which surfaces as TypeError: fetch failed.

The result is that composio.files.upload() has been broken on Node 22+ since the feature was introduced (commit 84d4381 / PR #1670, shipped in 0.1.29 on 2025-06-19), which in turn broke every file_uploadable connector tool that relies on the BE staging path — Instagram media (INSTAGRAM_POST_IG_USER_MEDIA with image_file), Drive uploads, Slack file shares, etc.

Fixes #3548.

What changed

   const uploadResponse = await fetch(signedURL, {
     method: 'PUT',
     body: uploadBuffer,
     headers: {
       'Content-Type': mimeType,
-      'Content-Length': contentBytes.length.toString(),
     },
   });

I left a short comment above the call so this isn't reintroduced by a future "let's set the headers explicitly" cleanup.

Why this works

Per the WHATWG Fetch spec, Content-Length is computed by the implementation from the body. undici enforces this strictly: a user-supplied Content-Length is treated as an invalid argument and the request is rejected before any bytes leave the client. Dropping the manual header lets fetch derive the correct value from uploadBuffer automatically.

Verification

End-to-end against @composio/core@0.10.0 with this change applied to a patched node_modules:

composio.files.upload({ file, toolSlug: 'INSTAGRAM_UPLOAD_FILE', toolkitSlug: 'INSTAGRAM' }) with a ~760 KB JPEG → R2 PUT succeeds, s3key returned.
Downstream INSTAGRAM_POST_IG_USER_MEDIA with image_file: { name, mimetype, s3key } posts successfully.
Reproduces the original failure (TypeError: fetch failed / InvalidArgumentError: invalid content-length header) on @composio/core@0.10.0 without this change on Node v24.16.0 and v22.x.

Sequence observed in production logs (matching threads in our DB):

step	image arg	result
before fix	`image_file: { maisonai_file: ... }` → staged via `composio.files.upload`	ERROR (`invalid content-length header`)
after fix	same	SUCCESS (R2 PUT → `s3key` → `INSTAGRAM_POST_IG_USER_MEDIA` → publish)

Notes

The bug went unnoticed for ~12 months. From a quick scan of the test suite and issue tracker, the existing file-upload tests use very small payloads where undici sometimes lets a manual Content-Length through; anything close to a real-world image consistently fails. Might be worth a regression test with a non-trivial payload, but I left that out of this PR to keep the diff minimal.
Happy to add a regression test if maintainers prefer.

References

Issue: #3548
Affected file: ts/packages/core/src/utils/fileUtils.node.ts
Introducing commit: 84d4381 (PR #1670)
WHATWG Fetch — forbidden request headers: https://fetch.spec.whatwg.org/#forbidden-request-header
undici: https://github.com/nodejs/undici

@ThrouMisi1d ago

Correction / scope refinement (apologies for the imprecision in the original report):

The trigger is more specific than "Node 22+ in general". After further testing:

Standalone Node v24.16.0 using the bundled undici (7.25.0): the manual Content-Length is accepted and composio.files.upload() succeeds even with ~700 KB payloads.
Next.js dev server (Node v24.16.0) with node_modules/.pnpm/undici@7.27.0 in the dependency graph: same call, same payload, fails with TypeError: fetch failed (cause: InvalidArgumentError: invalid content-length header, UND_ERR_INVALID_ARG).

Captured cause stack from the failing path:

InvalidArgumentError: invalid content-length header
    at processHeader (node_modules/.pnpm/undici@7.27.0/.../lib/core/request.js:421:13)
    at new Request (node_modules/.pnpm/undici@7.27.0/.../lib/core/request.js:214:11)
    ...
    at fetch (node:internal/bootstrap/web/exposed-window-or-worker:83:12)
    at uploadFileToS3 (.../@composio/core/dist/fileUtils.node-Dq7ebZPC.mjs:320:31)

So the precise statement is:

uploadFileToS3 fails on any host that uses (or transitively pulls in) undici@7.27.0 or later as the fetch dispatcher.

This is what next@16.2.7 (the version we're on) installs into node_modules. Other frameworks that ship a newer undici than the one Node bundles will be affected the same way; environments using only the Node-bundled undici 7.25.x are not affected yet — but the underlying issue (manually setting Content-Length is rejected by undici's isValidContentLengthHeaderValue / forbidden-header rules) will surface as undici tightens validation in future releases.

The proposed fix in #3549 (drop the manual header, let undici compute it from body) is correct regardless of undici version: spec-wise Content-Length is meant to be computed by the implementation. The fix is forward-compatible.

What does NOT change:

The root cause (manual Content-Length header in uploadFileToS3).
The fix (1-line removal).

▸ 1 bot/status comment hidden

@vercel[bot]1d ago

@ThrouMisi is attempting to deploy a commit to the Composio Team on Vercel.

A member of the Team first needs to authorize it.

loading diff…

Summary

Fixes #3548.

What changed

const uploadResponse = await fetch(signedURL, { method: 'PUT', body: uploadBuffer, headers: { 'Content-Type': mimeType, - 'Content-Length': contentBytes.length.toString(), }, });

I left a short comment above the call so this isn't reintroduced by a future "let's set the headers explicitly" cleanup.

Why this works

Verification

End-to-end against @composio/core@0.10.0 with this change applied to a patched node_modules:

composio.files.upload({ file, toolSlug: 'INSTAGRAM_UPLOAD_FILE', toolkitSlug: 'INSTAGRAM' }) with a ~760 KB JPEG → R2 PUT succeeds, s3key returned.

Downstream INSTAGRAM_POST_IG_USER_MEDIA with image_file: { name, mimetype, s3key } posts successfully.

Reproduces the original failure (TypeError: fetch failed / InvalidArgumentError: invalid content-length header) on @composio/core@0.10.0 without this change on Node v24.16.0 and v22.x.

Sequence observed in production logs (matching threads in our DB):

step

image arg

result

before fix

image_file: { maisonai_file: ... } → staged via composio.files.upload

ERROR (invalid content-length header)

after fix

same

SUCCESS (R2 PUT → s3key → INSTAGRAM_POST_IG_USER_MEDIA → publish)

Notes

The bug went unnoticed for ~12 months. From a quick scan of the test suite and issue tracker, the existing file-upload tests use very small payloads where undici sometimes lets a manual Content-Length through; anything close to a real-world image consistently fails. Might be worth a regression test with a non-trivial payload, but I left that out of this PR to keep the diff minimal.

Happy to add a regression test if maintainers prefer.

InvalidArgumentError: invalid content-length header at processHeader (node_modules/.pnpm/undici@7.27.0/.../lib/core/request.js:421:13) at new Request (node_modules/.pnpm/undici@7.27.0/.../lib/core/request.js:214:11) ... at fetch (node:internal/bootstrap/web/exposed-window-or-worker:83:12) at uploadFileToS3 (.../@composio/core/dist/fileUtils.node-Dq7ebZPC.mjs:320:31)

@ThrouMisi1d ago

Further refinement / re-framing

After more careful testing I want to walk back the "this is a bug in Composio SDK" framing. The picture is more nuanced and the SDK isn't doing anything spec-violating per HTTP RFC. The right framing is compatibility hardening for strict undici environments, not a bug fix.

What I actually verified

Plain node (v24.16.0, bundled undici 7.25) calling the SDK: composio.files.upload() succeeds with a 700 KB JPEG. No issues.
Same Node version, but explicitly using node_modules/.pnpm/undici@7.27.0 (the version Next.js pulls in) calling undici.fetch directly with Content-Length: '800000' on an Uint8Array(800_000) body to https://httpbin.org/put: succeeds.
Next.js 16.2.7 dev server (Node v24.16.0, with undici@7.27.0 in node_modules), native fetch with the same Content-Length header to https://httpbin.org/put: fails with TypeError: fetch failed / cause: InvalidArgumentError: invalid content-length header / UND_ERR_INVALID_ARG.

So the failing path is specifically: Node's built-in fetch, when its dispatcher is the node_modules copy of undici 7.27.0 (which is what next@16.2.7 ends up using). undici, as a standalone fetch, accepts the header; Node's built-in fetch path through the node_modules dispatcher rejects it.

What that means

Per HTTP RFC, Content-Length: <value matching body> is perfectly valid. The SDK isn't violating anything.
Per WHATWG Fetch (browser), Content-Length is a forbidden request header that the implementation must compute. undici is gradually aligning with that — strictness landed around v7 — and the way Node's built-in fetch routes through node_modules-installed undici when one is present, this strictness reaches server-side code that worked perfectly fine on older runtimes.
The SDK's choice to set Content-Length was reasonable for Node-targeted code. There's no bug per se.

What I'm proposing now

I still think dropping the manual Content-Length is the right change, but as a defensive compatibility improvement, not a bug fix. Concretely:

It restores compatibility with Next.js >= ~16.x (and any host that uses strict undici as its global dispatcher).
It is forward-compatible: even environments that currently accept the header will continue to work, because fetch will compute the same value from body.
It costs nothing — undici sets the correct Content-Length anyway.

This is essentially the same change as you'd make today to be ready for a future Node release that ships a stricter built-in undici.

Apologies for the earlier framings — I overstated both "Node 22+" and "this is a bug". The 1-line fix in #3549 still seems worth merging on compatibility grounds, but please feel free to close either of these if you'd rather wait for Node/undici to settle.