undici request() and ws server both throw 'Cannot read properties of undefined' at the transport layer despite compiling cleanly #10797

Activity

1. proggeramlug

   added

   package-auditFound by the 2026 package audit: compiling real npm packages from source instead of native bindingsFound by the 2026 package audit: compiling real npm packages from source instead of native bindings

   on Sep 20, 2026
2. proggeramlug commented on Sep 20, 2026

   

   proggeramlug

   on Sep 20, 2026

   ContributorAuthor

   More actions

   Re-examine these two before investing in them — two of the four blockers from the same probe wave have now turned out not to be what they were reported as.

   • cheerio.load() returns a callable object that reports typeof 'function' but throws 'string "h2" is not a function' when invoked #10796 (cheerio) — reported as a callable-object dispatch defect. Could not be reproduced. Real cheerio from dist/esm works byte-identically to Node; the reported symptom came from routing around Cross-module inlining copies Enum.Member references into the importer: "enum member X.Y not found in enums table" #10417 (cross-module enum inlining) with PERRY_ALLOW_PARTIAL_CODEGEN=1, which produces a different failure. Cheerio's real blocker is Cross-module inlining copies Enum.Member references into the importer: "enum member X.Y not found in enums table" #10417.
   • class X extends Stream (the bare node:stream base) throws 'is not a constructor' — #10649 covers only Readable/Writable/Duplex/Transform; blocks nodemailer #10798 (nodemailer / bare Stream) — the extends Stream gap was real and is fixed (PR fix(runtime): dispatch node:stream super() through the legacy Stream base #10805), but the TypeError: is not a constructor reported in the issue did not reproduce for any genuine extends Stream shape, including nodemailer's own XOAuth2 path, which already worked on pristine main. That exact error came from something else entirely: requiring a compiled package's internal file from outside the package yields a class export with typeof "object", which reproduces for a plain class with no heritage at all. Filed as perry.compilePackages: a compiled package's internal file, required from OUTSIDE the package, exports a class as typeof object (not function) — new X() throws 'is not a constructor' #10806.

   What that implies for this issue

   Both false readings share a cause: the probe exercised these packages in ways that differ from how a program actually consumes them — routing around a hard failure with a partial-codegen flag in one case, reaching into package internals in the other. Neither symptom was a lie; both were real observations of something other than the stated defect.

   So before anyone spends a day on undici or ws:

   1. Reproduce each from a plain, ordinary consumer — a normal import/require of the package's public entry point, no partial-codegen flags, no reaching into internals, pinned to the version in [bindings.<pkg>.upstream].
   2. Check perry.compilePackages: a compiled package's internal file, required from OUTSIDE the package, exports a class as typeof object (not function) — new X() throws 'is not a constructor' #10806 first for ws. Its reported failure is Cannot read properties of undefined (reading 'destroy') immediately after a byte-correct handshake — and ws is exactly the kind of package where a server implementation reaches across internal module boundaries. If the probe's fixture touched internals, perry.compilePackages: a compiled package's internal file, required from OUTSIDE the package, exports a class as typeof object (not function) — new X() throws 'is not a constructor' #10806 could produce a symptom like this.
   3. Check Cross-module inlining copies Enum.Member references into the importer: "enum member X.Y not found in enums table" #10417 for both, as cheerio's case showed a hard compile failure can be routed around into a misleading runtime error.

   The underlying defects may well be real — undici's failure before any TCP connect, and ws's correct handshake followed by an undefined socket, are both specific and plausible. This is not a claim that they are artifacts. It is that two of four from this batch were, so the reproduction should be re-established from a clean consumer before the investigation is scoped.

   Method note worth keeping

   A probe that reports "package X fails with error E" is reporting what it observed, not necessarily what a user would hit. The observation is still valuable — it is what surfaced #10806 and #10417's reach — but the framing "this package is blocked by E" carries an inference the probe did not test. Recording the fixture alongside the error, not just the error, would have made both of these visible immediately.
3. proggeramlug commented on Sep 21, 2026

   

   proggeramlug

   on Sep 21, 2026

   ContributorAuthor

   More actions

   Re-established both probes from clean public-entry consumers on current main (47ade47327), with the package versions from this issue and no partial-codegen flags or internal-file imports. Neither reported exception reproduces.

   ws@8.21.1

   Fixture imports { WebSocketServer, WebSocket } from ws, starts a local server, and connects a public client. It compiles and runs, but now stops at:

   Error: Unexpected server response: 426
   

   The original post-handshake undefined.destroy crash does not occur.

   undici@8.9.0

   Fixture imports { request } from undici and requests a local node:http server. The clean 111-module source graph reaches link, then is blocked by the llhttp WebAssembly dependency:

   undefined reference to js_webassembly_module_new
   

   The original pre-connect undefined.length runtime failure therefore is not currently reachable from the supported public consumer path.

   These are distinct current blockers, not evidence for the transport-object hypothesis in the issue, and they should be split/reframed before code changes are proposed. I am not opening a speculative/no-op PR for #10797.
4. proggeramlug commented on Sep 21, 2026

   

   proggeramlug

   on Sep 21, 2026

   ContributorAuthor

   More actions

   Closing this combined report because neither stated undefined failure reproduces from clean public-entry consumers on current main. The current, distinct blockers are now tracked separately as #10888 (ws, HTTP 426) and #10889 (undici, missing WebAssembly runtime symbol).
5. proggeramlug

   closed this as not plannedon Sep 21, 2026