edge-runtime

Bug Report Current behavior leaves an HTTP request open when the web handler returns a rejected Promise. The rejection is unhandled because the in has no rejection handler. In a local HTTP server reproduction, received and remained . Expected behavior/code The adapter should settle the Node response when an asynchronous web handler fails, without an unhandled rejection or a hanging connection. Possible solution Handle rejection in , ending or destroying the as appropriate, and add a rejected-handler case to . Additional context/screenshots Reproduction using the built and packages: On at , Node 22.22.3, I compiled the handler source with esbuild and exercised the resulting adapter through an actual Node HTTP server. The local reproduction substituted Node's for the primitives package because the repository's build script uses , which is unavailable in this Windows shell. It printed from and . The full package build was not verified here.

The current package and on still use as the build dependency. The package compiles that Undici copy into and , including the implementation exported by the package root. Because the copy is frozen into those files, updating or overriding Undici in a consumer project does not change the implementation executed by . Undici 6.21.0 is within the affected range of the already-public WebSocket 64-bit payload-length parser advisory. The 6.x fix was released in 6.24.0: https://github.com/advisories/GHSA-f269-vfmq-vjvj This can be fixed within the existing Undici 6.x line; it does not require the previously proposed major upgrade to Undici 7.x. The packaged identity can be verified from the module paths retained in the published bundles: Could be updated to a patched Undici 6.x release, the and artifacts regenerated, and a new version published? A dependency-only change without rebuilding and republishing would not update the copy in the existing package.

Summary drops a valid attribute in 6.0.0. Constructing from an existing deletion header and then setting an unrelated cookie rewrites the original header without . If the original header has no fallback, the emitted header loses its deletion instruction. Steps to reproduce 1. Create an empty directory and install the current published package: 2. Save this standalone example as : 3. Run . This exercises the cookie helper directly. Expected behavior Parsing the existing header preserves . Setting keeps on , and both assertions pass. The existing cookie's deletion instruction survives an unrelated cookie mutation. Actual behavior The parsed cookie has no property. After , the original cookie's header has neither nor : The first assertion fails with . The script exits with code 1. Affected area parses to a number, then filters properties by truthiness and removes zero. stores that parsed result and rewrites the complete header list on a later . Runtime or environment 6.0.0, the current npm release. Node.js v22.23.2 and npm 10.9.8 for the standalone reproduction. The same parse failure reproduces directly against on at commit . Equivalent header loss also reproduces through in Next.js 16.3.8, whose bundled cookie package metadata reports 6.0.0. The standalone example above isolates the behavior in this package. Evidence Conversion to a number followed by truthiness-based compaction. Parsing existing headers in the constructor and rewriting them after . The regression check is the pair of assertions in the reproduction. Both pass in a disposable local comparison that preserves numeric zero during compaction. Impact Code that starts with a valid cookie deletion header and later mutates another response cookie emits a different expiry contract for the original cookie. is a valid deletion instruction; applications should be able to combine these response operations without losing it. Additional context This differs from #348, which fixed serializing a cookie supplied directly with . The reproduction here starts by parsing an existing header. #941 and #995 addressed the hyphenated attribute name and covered parsing a positive value of 1000; the numeric-zero case still fails.