@composio/core: drop manual Content-Length in S3 upload PUT (compat with strict undici as built-in fetch dispatcher; e.g. Next.js 16)

[ThrouMisi]

Summary

composio.files.upload() always fails on Node.js 22+ with TypeError: fetch failed (cause: InvalidArgumentError: invalid content-length header, UND_ERR_INVALID_ARG).

Root cause: uploadFileToS3 in ts/packages/core/src/utils/fileUtils.node.ts passes a manual Content-Length header to fetch() (line 217 on main). Node.js's built-in fetch (undici) rejects any request that has a user-supplied Content-Length header — undici computes it from the body itself and refuses to allow a manual one to avoid HTTP request smuggling. The PUT to the presigned R2 URL never leaves the client.

This affects every file_uploadable connector tool (Instagram media, Drive uploads, Slack file shares, etc.) when the host runtime is Node.js 22+ with built-in fetch.

Reproduction

Environment:

• Node.js v24.16.0 (also reproduced on v22.x)
• @composio/core@0.10.0
• Manual call: composio.files.upload({ file, toolSlug, toolkitSlug }) with a small File (e.g. 760 KB JPEG)

Minimal repro:

import { Composio } from '@composio/core'

const composio = new Composio({
  apiKey: process.env.COMPOSIO_API_KEY,
  dangerouslyAllowAutoUploadDownloadFiles: true,
})

// any reasonably-sized buffer (>~64KB seems to trigger consistently)
const bytes = new Uint8Array(800_000)
const file = new File([bytes.buffer], 'test.jpg', { type: 'image/jpeg' })

try {
  await composio.files.upload({
    file,
    toolSlug: 'INSTAGRAM_UPLOAD_FILE',
    toolkitSlug: 'INSTAGRAM',
  })
} catch (err) {
  console.log(err.name, err.message)
  console.log('cause:', err.cause?.name, err.cause?.message, err.cause?.code)
}

Output:

TypeError fetch failed
cause: InvalidArgumentError invalid content-length header UND_ERR_INVALID_ARG

Note: With very small payloads (e.g. 1 KB) the request can sometimes succeed because undici's validation behavior differs at certain size boundaries, but anything close to a real-world image consistently fails.

Root cause (ts/packages/core/src/utils/fileUtils.node.ts)

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

Per the WHATWG Fetch spec and undici's implementation, Content-Length is a forbidden request header for user code — undici sets it automatically from the body. Supplying it explicitly results in InvalidArgumentError. See undici source: lib/web/fetch/headers.js (forbidden header check).

Suggested fix

Drop the manual Content-Length. fetch will compute it from uploadBuffer automatically:

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

I've validated this locally against @composio/core@0.10.0 (patched node_modules): with the line removed, R2 PUT succeeds, s3key is returned, and downstream connector calls (verified with INSTAGRAM_POST_IG_USER_MEDIA using image_file: { name, mimetype, s3key }) post successfully.

Happy to send a PR if useful.

Impact

Until this is fixed, any project that relies on staging files via the SDK on a modern Node runtime cannot use file_uploadable connector tools through the BE staging path. Workarounds we observed in production:

• Pass an HTTPS URL via image_url (when the connector accepts URLs) — bypasses staging.
• Have the LLM use COMPOSIO_REMOTE_WORKBENCH to upload the file inside Composio's sandbox — works but increases token cost and depends on the model being capable enough to drive that multi-step flow.

Neither of these are good defaults for production: the URL route requires public/signed URLs and isn't always available, and the workbench route is unreliable on smaller models.

References

• Affected file: https://github.com/ComposioHQ/composio/blob/main/ts/packages/core/src/utils/fileUtils.node.ts#L217
• WHATWG Fetch — forbidden request headers: https://fetch.spec.whatwg.org/#forbidden-request-header
• undici docs on auto-Content-Length: https://github.com/nodejs/undici

[ThrouMisi]

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).
• The end-to-end verification (R2 PUT succeeds, downstream connector tools post successfully).

What does change:

• The "affected runtimes" framing. It's "undici >=7.27.0 as the dispatcher", not "Node 22+ generally".

Sorry for the over-broad scoping in the original report.

[ThrouMisi]

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

1. Plain node (v24.16.0, bundled undici 7.25) calling the SDK: composio.files.upload() succeeds with a 700 KB JPEG. No issues.
2. 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.
3. 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.