Repository navigation
fix: Bump undici from 6.28.1 to 6.29.1 and 7.29.1 to 7.30.1 - #636
Conversation
|
🚀 Thanks for opening this pull request! We appreciate your effort in improving the project. Please let us know once your pull request is ready for review. Tip
Note Please respond to review comments from AI agents just like you would to comments from a human reviewer. Let the reviewer resolve their own comments, unless they have reviewed and accepted your commit, or agreed with your explanation for why the feedback was incorrect. Caution Pull requests must be written using an AI agent with human supervision. Pull requests written entirely by a human will likely be rejected, because of lower code quality, higher review effort and the higher risk of introducing bugs. Please note that AI review comments on this pull request alone do not satisfy this requirement. Our CI and AI review are safeguards, not development tools. If many issues are flagged, rethink your development approach. Invest more effort in planning and design rather than using review cycles to fix low-quality code. |
|
No actionable comments were generated in the recent review.
 |
| Layer / File(s) | Summary |
|---|---|
Update undici lock entries package-lock.json |
The current and legacy dependency sections update undici versions, resolved URLs, and integrity hashes for the @semantic-release/github, expo-server-sdk, and top-level entries. |
Priority:
Estimated code review effort: 1 (Trivial) | ~5 minutes
Merge Risk: 
56e52
-
No merge-blocking risk is identified in this lockfile-only dependency update.
Pre-merge checks: 
-
Check name Status Explanation Title check The title begins with the allowed fix:prefix, uses capitalization after the prefix, and accurately describes theundicidependency updates.Linked Issues check Issue #634requires updating undici from 7.29.1 to 7.30.1 and from 6.28.1 to 6.29.1 in the same change. The whole-PR diff against the merge base changes only package-lock.json, in these entries: node_…Out of Scope Changes check The whole-PR diff against the merge base contains one file, package-lock.json. All changed hunks update only the version, resolved, and integrity fields of the three undici entries that issue #634nam…Security Check The pull request changes only package-lock.json. The semantic diff contains only version, resolved URL, and integrity updates for undici 7.29.1→7.30.1 and 6.28.1→6.29.1. No application code or securit… Engage In Review Feedback PASS: The supplied review metadata shows zero actionable findings and no CodeRabbit review threads. No feedback comment required engagement, implementation, or reviewer agreement. Description check The PR description is thorough and matches the template's intent. It gives the issue reference (Closes #634) and a detailed approach covering the three undici lock-file entries, the security alerts re…Full details: Linked Issues check
-
Explanation
Issue
#634requires updating undici from 7.29.1 to 7.30.1 and from 6.28.1 to 6.29.1 in the same change. The whole-PR diff against the merge base changes only package-lock.json, in these entries: node_modules/expo-server-sdk/node_modules/undici and node_modules/@semantic-release/github/node_modules/undici (7.29.1 to 7.30.1), and node_modules/undici (6.28.1 to 6.29.1). Each entry has a new version, resolved URL, and integrity hash. The same three changes appear in the packages section and the lockfileVersion 2 dependencies section. Both version bumps land together, as the issue requires. The issue's remaining items, the security and reliability fixes, come from the upstream releases the lock file now pins. Those fixes are not separate code tasks in this repository. Issue#5663is closed and is background only, so it adds no requirements. The copy bundled inside npm (6.29.0) is not in the issue's scope. The PR description says the lock file cannot change it, and the issue does not ask for that change. No coding requirement is unmet. The security claims in the PR description about upstream releases were not checked against upstream sources. They do not change this verdict.
Full details: Out of Scope Changes check
-
Explanation
The whole-PR diff against the merge base contains one file, package-lock.json. All changed hunks update only the version, resolved, and integrity fields of the three undici entries that issue
#634names. No source, test, workflow, or manifest file changed. The closed issue#5663(proto cookie fix) is background only. The PR does not implement it, and the diff shows no related change. Every change in the diff is tied to the linked issue, so no out-of-scope change exists.
Full details: Security Check
-
Explanation
The pull request changes only package-lock.json. The semantic diff contains only version, resolved URL, and integrity updates for undici 7.29.1→7.30.1 and 6.28.1→6.29.1. No application code or security-sensitive logic changed, and the production expo-server-sdk copy is moved to the patched 7.30.1 release. The unchanged npm-bundled undici 6.29.0 is pre-existing and is not introduced by this pull request.
Full details: Description check
-
Explanation
The PR description is thorough and matches the template's intent. It gives the issue reference (Closes
#634) and a detailed approach covering the three undici lock-file entries, the security alerts resolved, the alerts that remain open because of the bundled npm copy, an empirical runtime check, and a changelog-level review of the breaking-change surface. It does not follow the template's exact headings (Pull Request, Issue, Approach, Tasks), and the Tasks checklist (Add tests, Add changes to documentation) is absent. The license and security-policy lines are also missing. Those gaps are non-critical for a lock-file-only dependency bump, so the description is mostly complete.
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #636 +/- ##
=======================================
Coverage 99.18% 99.18%
=======================================
Files 11 11
Lines 1841 1841
=======================================
Hits 1826 1826
Misses 15 15 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
## [8.5.8](8.5.7...8.5.8) (2026-10-27) ### Bug Fixes * Bump undici from 6.28.1 to 6.29.1 and 7.29.1 to 7.30.1 ([#636](#636)) ([75d6ad9](75d6ad9))
|
🎉 This change has been released in version 8.5.8 |
Closes #634
Lock-file-only update of the three
undicicopies that the lock file controls:node_modules/expo-server-sdk/node_modules/undici7.29.1 → 7.30.1. Production;expo-server-sdk6.1.0 declares^7.2.0.node_modules/@semantic-release/github/node_modules/undici7.29.1 → 7.30.1. Development;@semantic-release/github12.0.10 declares^7.0.0.node_modules/undici6.28.1 → 6.29.1. Development, via@semantic-release/npm→@actions/core→@actions/http-client4.0.0, which declares^6.23.0.npm ls undici --omit=devshows only the copy underexpo-server-sdk, which the EXPO push sender uses.@parse/node-apnandfirebase-admindon't depend onundici.The copy bundled inside
npm(node_modules/npm/node_modules/undici6.29.0, via@semantic-release/npm→npm11.21.1 →node-gyp12.4.0) ships in thenpmtarball and can't be changed through the lock file.Security
Dependabot alerts resolved by this PR:
>= 7.18.0, < 7.30.1>= 7.15.0, < 7.30.1>= 7.0.0, < 7.30.1After this PR, no
undici7.x copy below 7.30.1 is left in the lock file.Alerts that stay open because of the copy bundled in
npm11.21.1:>= 6.23.0, < 6.29.1). The root copy moves out of range to 6.29.1, but the bundled copy 6.29.0 is still in range. Dependabot counts bundled copies here: alerts 239, 241 and 245 (< 6.28.1) only closed when refactor: Bump npm from 11.20.0 to 11.21.1 #630 moved the bundled copy from 6.28.0 to 6.29.0, although the root copy was already 6.28.1.npm11.21.1 is the newest 11.x release, and@semantic-release/npmrequiresnpm^11.6.2. The alert stays open until annpm11.x release bundlesundici6.29.1 or later.>= 6.5.0, < 6.29.1) is already auto-dismissed. The bundled copy stays in its range for the same reason.How the advisories reach the production copy:
expo-server-sdkonly usesfetchfromundici. It sends a POST to the Expo push API withAccept-Encoding: gzip, deflate, readsresponse.statusandresponse.text(), and passes the adapter'shttpAgentoption asdispatcherwhen set.expo-server-sdksets nointegrityoption and uses no EventSource.Empirical check
Each case ran in its own Node.js 22.19.0 process. It called the adapter's
EXPO.send()→expo-server-sdksendPushNotificationsAsync()against a local HTTP server (EXPO_BASE_URL=http://127.0.0.1:<port>, no access token). The two runs used production installs (npm ci --omit=dev) of themasterlock file and of this one. The module cache showed that onlynode_modules/expo-server-sdk/node_modules/undiciwas loaded: 7.29.1 and 7.30.1 respectively.master)gzipdeflateGZIP(upper case)expo-server-sdk)Error: "to" must be a valid push token(statusCode400,codeVALIDATION_ERROR)gzipbodyTypeError: terminated, causeError: incorrect header checkgzipcodingsgzipcodings with a bodyTypeError: fetch failed, causeError: too many content-encodings in response: 6, maximum allowed is 5gzipcodings, connection closed before the bodySocketError: other side closedabout 100 ms later, which crashes the processChanges
undici 7.29.1 → 7.30.1
headersandtrailersevents and is marked completed after a successful upgrade, so a laterabort()of that request no longer errors it or destroys the socket. An exception thrown by the upgrade handler now errors the request.RetryHandlerhonor backpressure ([Backport v7.x] fix: honor backpressure in decompression interceptor nodejs/undici#5837). This replaces the 64 MiB per-stage limit that 7.29.1 added and changes themaxSizedefault back to0(no limit).maxSizeremains an opt-in per-stage limit.Agentdropped function-valued TLS options such ascheckServerIdentitycompose(redirect(), cache())Content-Encodingvalues could crash the processdecompressinterceptor could escape as uncaught exceptionsgetCookies()returns a null-prototype object.setCookie()writesExpires=for a numericexpiresof0, and drops a non-finite or out-of-range numericexpires.eventSource: { maxEventSize }to configure the EventSource parser limits added for GHSA-4qv8-2p9j-2685. The limits are active by default, and0disables them:maxEventSizedefaults tobuffer.kStringMaxLength.min(131072, max(1024, floor(maxEventSize / 128))), which is 131072 by default.dispatcherinit option now defaults togetGlobalDispatcher().undici 6.28.1 → 6.29.1
headersandtrailersevents.abort()destroyed the socket or HTTP/2 stream and also errored the request. It now only destroys the socket or stream.'ready'. Later response headers and stream errors are reported throughonUpgradeResponseandonUpgradeError.Agentdropped function-valued TLS options such ascheckServerIdentityContent-Encodingvalues could crash the processeventSource: { maxEventSize }to configure the EventSource parser limits added for GHSA-4qv8-2p9j-2685. The limits are active by default, and0disables them:maxEventSizedefaults tobuffer.kStringMaxLength.min(131072, max(1024, floor(maxEventSize / 128))), which is 131072 by default.dispatcherinit option now defaults togetGlobalDispatcher().Lock file
Generated with
npm update undici --ignore-scripts --package-lock-only(npm 10.9.3). The diff only changesversion,resolvedandintegrityof the three entries above, in both thepackagesand the lockfileVersion 2dependenciessections. It's identical to the lock file in #634.Both target versions declare the same Node.js engine range as the current versions:
>=20.18.1for 7.x and>=18.17for 6.x. The supported Node.js versions don't change. CI tests Node.js 20, 22 and 24.Breaking Changes
None
Code Changes Required
None. The upgrade is a drop-in replacement.
expo-server-sdkonly callsfetch. The empirical check shows the same results for normal, compressed, error, retried and malformed responses. The only difference is the crash fix.RetryAgent, EventSource and cookie helpers: neither the adapter nor any parent package (expo-server-sdk,@semantic-release/github,@actions/http-client) uses them. The decompressionmaxSize,RetryHandler, EventSource limit and dispatcher, and cookie changes don't apply.expo-server-sdksends afetchPOST. The development parents only send CONNECT throughProxyAgentwhen a proxy is configured, andrelease-automated.ymlconfigures none.fetchuses now runs with WebAssembly SIMD ([Backport v7.x] fix: selectively re-enable SIMD for ppc64 nodejs/undici#5794). This is a deliberate upstream change.expo-server-sdkuses the default global dispatcher unlesshttpAgentis configured, and it passes no TLS options. The TLS session cache fix only applies once the cache holds 100 sessions, while the adapter connects to a single origin.release-automated.ymlthrough the semantic-release plugins.@semantic-release/githubcallsfetchwith adispatcherthat is anew Agent()without options, or aProxyAgent({ uri })when a proxy is configured.@actions/http-clientonly usesProxyAgent. Neither parent passes TLS options, and thefetchchange only affects responses with more than five content codings.Summary by CodeRabbit