testing/transports

8 modules

• testing/transports/bootstrap.ts

  Stateless cross-process bootstrap.

  POSTs {bootstrap_path} against the running test binary with the preconfigured token + username + password, parses the BootstrapOutput envelope, captures the session Set-Cookie onto the supplied FetchTransport (which carries it on every subsequent call), and returns the keeper credentials.

  Fires exactly once per backend lifetime — spawn_backend calls it inside vitest's globalSetup. Per-test fixtures re-use the captured keeper credentials; fresh per-test accounts come from fixture.create_account() (signup+login through production RPC), not re-bootstrap. The hybrid reset model in default_cross_process_setup depends on this — re-bootstrap would race the bootstrap lock and in-memory caches.

• testing/transports/fetch_transport.ts

  Cookie-threading HTTP transport for cross-process tests.

  Wraps the global fetch against a base URL, carries cookies across requests in a Map-backed jar so the session cookie set on bootstrap is re-sent on every subsequent call. Satisfies the RpcTestTransport shape Hono.request already does — so every suite body that takes transport: RpcTestTransport works against a cross-process binary unchanged.

  The Origin header is threaded onto every request because the backend's allowlist ({ZZZ,ZAP,FUZ}_ALLOWED_ORIGINS) rejects mutations without an Origin. Cross-process tests run with ALLOWED_ORIGINS=http://localhost:*, so defaulting origin to the configured base_url is safe.

  The cookie jar is intentionally simple — it does not honour Domain, Path, Expires, or SameSite attributes. Cross-process tests always hit a single host:port, so name-keyed last-write-wins matches the behaviour real browsers exhibit against the same surface.

• testing/transports/raw_http.ts

  Raw-socket HTTP/1.1 exchanges, for tests that need to control exactly which bytes reach the server.

  fetch frames a request itself and sends all of it, so some server behaviors can't be reached through it: what a server does with two requests in one write, with duplicate or malformed headers, with a request head whose body never follows, or with a chunked body that is never terminated. This writes caller-built bytes over node:net and hands back what the server sent, plus just enough parsing to read a status or one whole response.

  Everything is latin1-decoded, so a string's length is its byte length.

  Plain TCP only: an https: URL is not spoken to over TLS, and the host must be a name or an IPv4 address — a bracketed IPv6 literal does not connect.

• testing/transports/sse_frame_reader.ts

  SSE frame reader over a ReadableStreamDefaultReader<Uint8Array>.

  Transport-agnostic core shared by the in-process SSE route suite (testing/sse_round_trip.ts, reading a Hono Response.body) and the cross-process transports/sse_transport.ts (reading a streaming fetch body): \n\n-delimited framing, a per-read timeout (so vitest can't hang on a stalled stream), and wait_for_close for server-initiated close detection (the auth-guard revocation seam).

• testing/transports/sse_transport.ts

  Cross-process Server-Sent Events transport.

  Opens a real streaming fetch against a spawned test binary's SSE endpoint, threading the session cookie captured by the sibling FetchTransport so the stream authenticates as the same account, then delegates frame parsing to the shared create_sse_frame_reader. Uses only built-in streaming fetch + TextDecoder — no extra dep.

  Mirrors how testing/transports/ws_transport.ts is the cross-process counterpart to the in-process WS harness; the in-process SSE route suite (testing/sse_round_trip.ts) shares the same create_sse_frame_reader over a Hono Response.body.

• testing/transports/ws_client.ts

  Shared WebSocket client surface for cross-backend tests.

  WsClient is the interface every in-process or cross-process WS test driver implements — send / request / close / messages / wait_for. Two impls today:

  • In-process — create_ws_test_harness in testing/ws_round_trip.ts. Drives register_action_ws against a fake Hono upgrade so the dispatcher's full path runs without the wire upgrade.
  • Cross-process — create_ws_transport in testing/transports/ws_transport.ts. Wraps the native WebSocket upgrade against a real running binary, threading the session cookie captured by FetchTransport.

  Wire-frame types + predicates also live here so both impls (and every shared assertion helper) reference one source.

• testing/transports/ws_raw_client.ts

  A raw-socket WebSocket client for tests that need to misbehave, or to control exactly which bytes reach the server when.

  A client library answers a close frame itself and sends nothing until its open event, so two server behaviors can't be reached through one: what the server does with a client that withholds its close frame, and what it does with frames that arrive with the handshake, before the connection can have been admitted. This speaks just enough RFC 6455 over node:net to do both — the upgrade request, masked client text frames, and unmasked server frames — and deliberately never replies to a close.

  Small frames only (payloads under 64 KiB, unfragmented), which is all the JSON-RPC traffic the suites send.

• testing/transports/ws_transport.ts

  Cross-process WebSocket transport.

  Implements the shared WsClient interface (see testing/transports/ws_client.ts) over a real WebSocket upgrade against a spawned test binary. The cookie captured by the sibling FetchTransport on bootstrap is threaded onto the upgrade request so the WS session authenticates as the same account.

  Uses the ws npm package — Node's native WebSocket (from undici) follows the WHATWG spec strictly and doesn't accept custom request headers on construction, so cookie-on-upgrade requires the ws package's headers option. fuz_app declares ws as an optional peerDependency — consumers wiring cross-process tests install it themselves (npm install --save-dev ws).