testing/transports

6 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/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_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).