@claxedo/workspace-relay 0.8.0 → 0.10.0

package/dist/synthetic.d.ts

@@ -1,60 +0,0 @@
-/**
- * T10: Synthetic end-to-end probe.
- *
- * Liveness depends on metrics; metrics can lie. A synthetic probe periodically
- * exercises the relay's HTTP path and records RTT so we have an independent
- * signal that the data path actually works.
- *
- * Implementation notes
- * --------------------
- * - The probe targets `${relayUrl}/health` rather than minting a Runtime
- *   Access Token and hitting `/workspaces/<id>/...`. `/health` validates HTTP
- *   connectivity end-to-end without pretending the Relay owns Control Plane
- *   token issuance.
- * - All clocks, timers and `fetch` are injectable so tests stay deterministic.
- * - "Loud" logs after 3 consecutive failures use `console.error` by default;
- *   pageability (PagerDuty / equivalent) is wired separately.
- */
-export type SyntheticProbeStats = {
-    successCount: number;
-    failureCount: number;
-    consecutiveFailures: number;
-    /** RTT (ms) of the most recent probe attempt. Undefined before the first probe completes. */
-    lastRttMs?: number;
-    /** p50 / p99 over the rolling RTT window. Undefined if no successes yet. */
-    p50?: number;
-    p99?: number;
-    /** Number of RTTs currently in the rolling window. */
-    windowSize: number;
-};
-export type SyntheticProbe = {
-    stop(): void;
-    stats(): SyntheticProbeStats;
-};
-export type SyntheticProbeOptions = {
-    /** Base URL of the relay, e.g. `http://127.0.0.1:7777`. No trailing slash required. */
-    relayUrl: string;
-    /** Probe cadence. Default 60_000 (60 s). */
-    intervalMs?: number;
-    /** Summary log cadence (p50/p99). Default 300_000 (5 min). */
-    summaryIntervalMs?: number;
-    /** Path to probe. Default `/health`. */
-    probePath?: string;
-    /** Rolling window size for RTT percentile calculation. Default 100. */
-    rttWindowSize?: number;
-    /** Number of consecutive failures that triggers a loud log. Default 3. */
-    loudFailureThreshold?: number;
-    /** Override `fetch`. Defaults to global `fetch`. */
-    fetch?: typeof fetch;
-    /** Override clock for tests. Defaults to `Date.now`. */
-    now?: () => number;
-    /** Override `setInterval` for tests. Defaults to global `setInterval`. */
-    setInterval?: typeof setInterval;
-    /** Override `clearInterval` for tests. Defaults to global `clearInterval`. */
-    clearInterval?: typeof clearInterval;
-    /** Loud-failure logger. Defaults to `console.error`. */
-    logError?: (msg: string, fields?: Record<string, unknown>) => void;
-    /** Periodic summary logger (p50/p99). Defaults to `console.log`. */
-    logSummary?: (msg: string, fields?: Record<string, unknown>) => void;
-};
-export declare function startSyntheticProbe(options: SyntheticProbeOptions): SyntheticProbe;

package/dist/upstream-websocket.d.ts

@@ -1,34 +0,0 @@
-/**
- * The relay's upstream WebSocket constructor, and the one place that names it.
- *
- * A relay client socket is proxied to a workspace runtime over a second,
- * outbound WebSocket that must carry the runtime's auth headers. Bun's global
- * `WebSocket` really does accept `(url, { headers })` — but that shape is not
- * expressible in this package's type program, for a reason that is worth
- * writing down once rather than rediscovering at the call site:
- *
- * `bun-types` yields its own `WebSocket` declaration to `lib.dom` whenever
- * `lib.dom` is loaded (`Bun.__internal.UseLibDomIfAvailable`), and `lib.dom`
- * declares only the `(url, protocols)` overload — on a `declare var`, which
- * cannot be augmented. So while `lib.dom` is in `tsconfig.json`, the real
- * constructor is unreachable through the global's type.
- *
- * Dropping `lib.dom` (as `bench/tsconfig.json` does) fixes THIS and breaks more
- * than it fixes: `bun-types`' `Request` constructor declares `string`,
- * `RequestInit & { url }` and `Request` inputs and no `URL` input at all, which
- * this package and its tests rely on.
- *
- * The assertion is therefore genuine — the type system cannot express the
- * value — and it is confined to this module so that the lint override excusing
- * it covers ~40 lines whose only job is this constructor, rather than blinding
- * the 4,000-line `bun.ts` that consumes it.
- */
-export type UpstreamWebSocketConstructor = {
-    new (url: string, options: Bun.WebSocketOptions): WebSocket;
-};
-/**
- * The constructor used to open the upstream socket: the caller's override when
- * one is supplied (tests inject fakes to drive open timeouts, pre-open queue
- * limits and abnormal closes), otherwise Bun's global `WebSocket`.
- */
-export declare function resolveUpstreamWebSocket(override?: UpstreamWebSocketConstructor): UpstreamWebSocketConstructor;

package/dist/user-hosted-forwarding.d.ts

@@ -1,40 +0,0 @@
-import type { RelayAccess } from "./auth";
-/**
- * The canonical "is this relay target user-hosted" rule.
- *
- * A user-hosted workspace runs on the user's own laptop (backing:
- * "local-worktree"); a cloud workspace runs on a dedicated cloud VM
- * (backing: "cloud-vm"). `RelayAccess` has exactly these two members, so
- * `access === "user-hosted"` and `access !== "cloud"` are equivalent — but
- * spelling the check either way at each call site invites drift if a third
- * access kind is ever added. Every caller that needs to branch on this
- * (choosing a forwarding path, tagging a socket, deciding whether to strip
- * Cookie) should go through this one predicate instead.
- */
-export declare function isUserHostedTarget(target: {
-    access: RelayAccess;
-}): boolean;
-export type WorkspaceRelaySocketKind = "user-hosted-client" | "client";
-/**
- * The socket-kind tag applied when a relay client is admitted against
- * `target`. A user-hosted target is multiplexed over the host tunnel
- * (`"user-hosted-client"`); a cloud target gets a direct upstream socket
- * (`"client"`).
- */
-export declare function socketKindFor(target: {
-    access: RelayAccess;
-}): WorkspaceRelaySocketKind;
-/**
- * Privacy rule: never forward the browser's `Cookie` header into a
- * user-hosted workspace. Its host process runs on the user's own laptop and
- * may share a cookie jar with the browser (e.g. localhost dev tooling), so
- * passing cookies through verbatim risks leaking session data to the host.
- * Cloud-vm workspaces sit behind a dedicated network boundary where session
- * cookies may legitimately be needed (e.g. workspace dashboards), so cloud
- * targets pass `Cookie` through unchanged.
- *
- * Returns a new `Headers` instance; `headers` is not mutated.
- */
-export declare function forwardHeadersFor(target: {
-    access: RelayAccess;
-}, headers: Headers): Headers;