refactor(runner): use node:http to fetch worker#4004
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughRemoves the undici dependency, refactors src/runner/proxy.ts to use Node's http.request for TCP and Unix socket requests with manual body/stream handling and header filtering, and adds comprehensive unit tests exercising TCP and Unix socket behaviors. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@test/unit/proxy.test.ts`:
- Around line 109-117: The test "forwards custom headers" uses res.json() whose
return type is unknown; update the body declaration in that test (the one using
fetchAddress and res.json()) to include a type assertion, e.g. assert the result
as an object with headers (for example: as { headers: Record<string, string> }),
so accessing body.headers is type-safe; locate the test block referencing
fetchAddress and change the body assignment to use this type assertion.
🧹 Nitpick comments (3)
src/runner/proxy.ts (1)
109-115:pipe()won't propagate source-stream errors — considerpipeline(); also,req.end(body)only acceptsstring | Buffer | Uint8Array.Two edge-case concerns with the body handling:
If the
ReadableStreamemits an error,pipe()won't forward it toreq, so the wrapping Promise may hang (no resolve or reject). Usingpipeline()fromnode:stream/promisesor manually wiring.on("error")on the readable side would make this more resilient.
req.end(body)on line 112 only acceptsstring | Buffer | Uint8Array, butBodyInitalso includesBlob,ArrayBuffer,FormData, andURLSearchParams. If any of these are ever passed, it would silently produce incorrect output or throw.Both are unlikely in the current dev-proxy context, so just flagging for awareness.
🔧 Optional: safer streaming with pipeline()
-import { Readable } from "node:stream"; +import { Readable, pipeline } from "node:stream";if (init!.body instanceof ReadableStream) { - Readable.fromWeb(init!.body as import("node:stream/web").ReadableStream).pipe(req); + const nodeBody = Readable.fromWeb(init!.body as import("node:stream/web").ReadableStream); + pipeline(nodeBody, req, (err) => { + if (err) reject(err); + }); } else if (init!.body) {test/unit/proxy.test.ts (2)
1-7: Usepatheinstead ofnode:pathper project coding guidelines.Line 3 imports
joinfromnode:path. The usage is for a Unix socket path, which is platform-specific anyway, but the guideline applies to all*.tsfiles.♻️ Suggested fix
-import { join } from "node:path"; +import { join } from "pathe";As per coding guidelines:
**/*.{js,ts}: Usepathefor cross-platform path operations instead ofnode:path.
84-86: Socket file not cleaned up after tests.
socketServer.close()stops listening but the.sockfile may remain on disk intmpdir(). Consider unlinking it inafterAllfor clean test runs.♻️ Optional cleanup
+import { unlinkSync } from "node:fs";afterAll(() => { socketServer?.close(); + try { unlinkSync(socketPath); } catch {} });
commit: |
This PR migrates from using undici to directly
node:httpto fetch the dev worker's socket.Improves stability (hopefully for windows), speed and also reduces install size (-1.46MB)