Releasing v3.24.1

[cb-alish]

v3.24.1 (2026-06-03)

---

Bug Fixes:

• Fixed Content-Length header being computed from the JavaScript string length (UTF-16 code units) instead of the UTF-8 byte length. Requests with non-ASCII payloads (e.g. accented characters, CJK, emoji) under-declared Content-Length and were rejected by Node's fetch/undici (≥ 7.26.0) with Request body length does not match content-length header. The header is now computed via Buffer.byteLength(data, 'utf8'). Resolves Content-Length request header is set to the string character count instead of the UTF-8 byte length → TypeError: fetch failed on any non-ASCII request body #119

Tests:

• ASCII form-urlencoded body — Content-Length matches the UTF-8 byte length of the serialized body.
• Multi-byte JSON body — Content-Length matches the UTF-8 byte length and is greater than the JS character count, ensuring the regression cannot return.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[hivel-marco]

PR Complexity Score: 2.5 - Simple

View Breakdown

• Lines Changed: 64
• Files Changed: 7
• Complexity Added: 5
• Raw Score: 29.78

Overview

This PR releases version 3.24.1 of the Chargebee Node client with a critical bug fix for how the Content-Length header is calculated. It ensures compatibility with Node’s fetch/undici (≥ 7.26.0) for requests containing non-ASCII payloads. The change updates request construction logic, adds regression tests, and bumps version metadata.

Key Changes

• Fixes Content-Length header computation to use Buffer.byteLength(data, 'utf8') instead of the JavaScript string length, preventing under-declared content lengths for multi-byte characters and avoiding Request body length does not match content-length header errors.
• Adds tests for ASCII form-urlencoded request bodies to confirm that Content-Length matches the UTF-8 byte length of the serialized body.
• Adds tests for multi-byte JSON payloads (e.g. accented characters, CJK, emoji) to ensure Content-Length reflects UTF-8 byte length and is greater than the JS character count, guarding against regressions.
• Bumps the client version to 3.24.1 across metadata and environment configuration, and documents the bug fix and tests in the changelog.

Risks & Considerations

• Any downstream code or middleware that assumes Content-Length matches JS string length rather than UTF-8 byte length might behave differently, though this change aligns with HTTP and Node standards.
• The fix relies on Buffer.byteLength with 'utf8'; if future encodings or non-UTF-8 bodies are introduced, this logic may need revisiting.
• Reviewers should verify that all request paths using RequestWrapper rely on this unified code path for setting Content-Length so there are no remaining edge cases.

File-level change summary

File	Change summary
CHANGELOG.md	Added v3.24.1 release notes describing the Content-Length bug fix and associated tests.
VERSION	Bumped library version from 3.24.0 to 3.24.1.
package-lock.json	Updated package version metadata from 3.24.0 to 3.24.1 in the lockfile.
package.json	Bumped npm package version from 3.24.0 to 3.24.1.
src/RequestWrapper.ts	Changed Content-Length header calculation to use Buffer.byteLength(data, 'utf8') instead of data.length.
src/environment.ts	Updated clientVersion constant to v3.24.1.
test/requestWrapper.test.ts	Added tests verifying Content-Length uses UTF-8 byte length for ASCII form-urlencoded and multi-byte JSON bodies.