Add Bun runtime support

[kriszyp]

• Replace node-unix-socket native addon with native reusePort (Node v22+)
• Add BunRequest adapter wrapping Web Fetch API Request
• Branch http.ts to use Bun.serve() with fetch handler when running on Bun
• Bridge Operations API (Fastify) to Bun via inject() in bunDelegateToNodeServer
• Add listenOnPortsBun() using Bun.serve({ reusePort: true }) per worker
• Support TLS/secure ports on Bun via Bun.serve({ tls: { cert, key } })
• Create UDS mirror sockets for secure ports via Bun.serve({ unix })
• Guard Node-specific APIs: v8, inspector, worker.performance, TLS monkey-patches
• Fix performance.eventLoopUtilization() NotImplementedError on Bun
• Skip Node version check when running on Bun
• Parameterize integration tests via HARPER_RUNTIME env var (node|bun)
• Add CI jobs to run integration tests and API tests on Bun

This also includes work for Windows fixes and runs the core integration tests on Windows.

Neither Windows nor Bun is running the full integration:api-tests. There are failures, and there will need to be follow-up work to provide more comprehensive support of these platforms/runtimes. But this should ensure basis support.

[heskew]

👀

[claude]

Auth bypass on Node.js (same concern as prior review, still unaddressed)

fastifyAuth.js trusts x-harper-internal-pre-auth-user without a Bun guard. On Bun this is safe — bunDelegateToNodeServer strips the header before fastify.inject(). On Node.js, Fastify receives the raw IncomingMessage via the unhandled-event cascade, with all client headers intact. Any client can forge this header and bypass authentication.

Suggested fix: gate the header check on the Bun runtime:

Suggested change

	if (preAuthUser) return next(null, JSON.parse(preAuthUser));
	const preAuthUser = typeof globalThis.Bun !== 'undefined' && req.headers?.[INTERNAL_USER_HEADER];

[claude]

ReferenceError on every static file scan (same concern as prior review, still unaddressed)

logger is not defined in this scope — the scoped logger is scope.logger (used correctly on line 32). This will throw on the first entry event fired by the static plugin, breaking static file serving entirely. Looks like a debug line accidentally left in.

Suggested change

	logger.error('static received entry', entry);
	scope.logger.debug('static received entry', entry);

Or just remove the line.

[claude]

Build failures silently ignored on Windows

continue-on-error: true suppresses all build failures (not just type warnings). Per repo policy, Harper core's build should pass cleanly — the tsc || true pattern is explicitly called out as not applicable here. A CI job that passes even when compilation fails provides false confidence.

The comment acknowledges existing type errors; those should be fixed before enabling the Windows build job, not masked. If this job is meant to be informational-only in the interim, consider making the whole job continue-on-error: true at the job level and documenting the known failures in a tracking issue.

[claude]

Blocker (re-raised from prior review — still unresolved): The comment says the header is stripped in bunDelegateToNodeServer, but that only covers the Bun code path. On Node.js, Fastify receives requests via the unhandled event at http.ts:279 with the raw nodeRequest — no header stripping occurs before this point. Any client can send x-harper-internal-pre-auth-user on Node.js to bypass auth.

Suggested change

	if (preAuthUser) return next(null, JSON.parse(preAuthUser));
	if (typeof globalThis.Bun !== 'undefined' && preAuthUser) return next(null, JSON.parse(preAuthUser));

[claude]

Blocker (re-raised from prior review — still unresolved): logger is not defined in this module. This throws ReferenceError: logger is not defined on the first entry event, breaking static file serving entirely. The available logger is scope.logger, but this line looks like a debug leftover and should simply be removed.

Suggested change

logger.error('static received entry', entry);

[cb1kenobi]

Good news, we should be able to remove this hack once we drop Node 20! 🎉

[cb1kenobi]

We can/should probably declare the type.

Suggested change

	#readable: any; // lazily created Readable stream
	#readable: Readable; // lazily created Readable stream

[cb1kenobi]

Already defined above

Suggested change

const isBun = typeof globalThis.Bun !== 'undefined';

[cb1kenobi]

Jarred mentioned worker.terminate() was not amazing.

[cb1kenobi]

shutdownWhenIdle is an interesting feature, do we no longer need this?

[cb1kenobi]

🤣

[claude]

AUTHORIZE_LOCAL widens to all clients on Bun, not just loopback.

fastify.inject() hardcodes req.socket.remoteAddress to '127.0.0.1' regardless of the real client IP (as the commit message acknowledges). This means when AUTHORIZE_LOCAL=true (DEV_MODE or AUTHENTICATION_AUTHORIZELOCAL), any client that reaches the Bun ops API port is authenticated as superuser — not just loopback clients. On Node.js, baseRequest carries the real socket IP so only actual 127.0.0.x/::1 clients are elevated.

Fastify's inject accepts a remoteAddress option to propagate the real IP. The fix is in bunDelegateToNodeServer (http.ts), not here:

Suggested change

	ip: req.socket?.remoteAddress ?? '',
	ip: req.socket?.remoteAddress ?? '',

Pass the real client IP through inject so this check works correctly:

// in bunDelegateToNodeServer (http.ts), change:
const injectResult = await fastify.inject({
    method: webRequest.method,
    url: url.pathname + url.search,
    headers,
    payload: body,
    remoteAddress: bunRequest?.ip,   // ← add this
});

Then req.socket.remoteAddress here reflects the real IP and AUTHORIZE_LOCAL stays loopback-only.

[claude]

Prior blocker still open: AUTHORIZE_LOCAL widens to all clients on Bun

fastify.inject() without remoteAddress causes Fastify's mock socket to report remoteAddress: '127.0.0.1'. When INTERNAL_USER_HEADER is absent (ops API requests where Harper auth didn't run), fastifyAuth.js falls into the shimRequest path and calls authentication() with ip: req.socket?.remoteAddress — which is always '127.0.0.1'. If AUTHORIZE_LOCAL is configured, every external client that reaches this port is elevated to superuser.

Suggested change

	});
	const injectResult = await fastify.inject({
	method: webRequest.method,
	url: url.pathname + url.search,
	headers,
	payload: body,
	remoteAddress: bunRequest?.ip,
	});

[claude]

Prior blocker still open: Windows CI silently ignores build failures

continue-on-error: true on the Build step means a broken dist/ artifact is uploaded and the downstream run-integration-tests-windows job runs against it. Per AGENTS.md, Harper core's build must pass cleanly. Either fix the type errors and remove this flag, or — if Windows is explicitly best-effort for this PR — move continue-on-error: true to the job level so the downstream test job is skipped instead of running on a broken artifact.

[claude]

The fastify.inject() call still doesn't pass remoteAddress, so req.socket.remoteAddress inside Fastify is always '127.0.0.1'. The new shimRequest path in fastifyAuth.js uses that value for ip, meaning any external client that reaches the ops API port gets AUTHORIZE_LOCAL elevation on Bun (commit 47ae9304e acknowledges this in its message: "ip comes from req.socket.remoteAddress which is '127.0.0.1' in inject").

Suggested change

	const injectResult = await fastify.inject({
	method: webRequest.method,
	url: url.pathname + url.search,
	headers,
	payload: body,
	const injectResult = await fastify.inject({
	method: webRequest.method,
	url: url.pathname + url.search,
	headers,
	payload: body,
	remoteAddress: bunRequest?.ip,

[claude]

Prior blocker still open: AUTHORIZE_LOCAL widens to all clients on Bun ops API

fastify.inject() without remoteAddress causes Fastify's mock socket to report remoteAddress: '127.0.0.1'. When INTERNAL_USER_HEADER is absent (the ops API path where auth.ts didn't run), fastifyAuth.js falls to the shimRequest branch and calls authentication() with ip: req.socket?.remoteAddress — which is always '127.0.0.1'. Any external client that reaches the Bun ops API port is then elevated to superuser whenever AUTHORIZE_LOCAL is configured.

Commit 47ae9304e explicitly acknowledges this in its message ("ip comes from req.socket.remoteAddress which is '127.0.0.1' in inject") but doesn't fix it.

Suggested change

	});
	const injectResult = await fastify.inject({
	method: webRequest.method,
	url: url.pathname + url.search,
	headers,
	payload: body,
	remoteAddress: bunRequest?.ip,
	});

[claude]

Prior blocker still open: Windows CI silently ignores build failures

continue-on-error: true on the Build step means a broken dist/ artifact is uploaded, and run-integration-tests-windows runs against it. Per AGENTS.md, Harper core's build must pass cleanly (tsc || true is explicitly not used here). Either fix the type errors and remove this flag, or move continue-on-error: true to the job level so the downstream test job is skipped on a failed build.

[claude]

Blocker (re-raise — unresolved from prior review): req.socket?.remoteAddress in a fastify.inject() context comes from light-my-request's mock socket, which defaults to '127.0.0.1' regardless of the real client's IP. auth.ts is not registered for the operations API port, so bunRequest.user is always null for ops API requests — meaning INTERNAL_USER_HEADER is never sent, and every ops API request falls into this shim path. The result: when AUTHORIZE_LOCAL is configured, all clients (including external) match ip.includes('127.0.0.') in auth.ts:245 and receive superuser access.

The fix is to pass the real client IP from bunRequest.ip through the inject call:

Suggested change

	headers: { asObject: Object.assign({}, req.headers) },
	ip: req.socket?.remoteAddress ?? '',

Change bunDelegateToNodeServer to include remoteAddress: bunRequest?.ip in the fastify.inject() options, so that req.socket.remoteAddress inside the handler reflects the actual client IP instead of light-my-request's 127.0.0.1 default.

[claude]

Blocker (unresolved from prior review): continue-on-error: true on the Build step means a broken Windows build silently passes, and the downstream run-integration-tests-windows job runs against a potentially incomplete dist/. Either fix the type errors so this flag can be removed, or move continue-on-error: true to the job level so the test job is skipped when the build fails.