@terminal3/t3n-sdk 3.4.1 → 3.4.3

package/dist/index.d.ts

@@ -1057,9 +1057,44 @@ declare class HttpTransport implements Transport {
     private timeout;
     private lastSetCookie;
     private lastResponseHeaders;
+    /**
+     * Cookie jar (`name -> value`) for non-browser callers. The session is
+     * node-local in-memory state, so once the load balancer pins a client
+     * to a node via its `GCLB` session-affinity cookie, every later request
+     * in the session must carry that cookie back or it gets re-balanced to
+     * a node that has never seen the handshake → `401 session not found`.
+     * Browsers replay the cookie automatically from their own jar (via
+     * `credentials: "include"`); plain `fetch` callers (Node demos, tests,
+     * server-side SDK usage) have no jar, so we keep one here. Empty in
+     * browsers — there `getSetCookie()` is unavailable and a script-set
+     * `Cookie` header is forbidden, so this stays inert.
+     */
+    private cookieJar;
     constructor(baseUrl: string, timeout?: number);
     getLastSetCookie(): string | null;
     getLastResponseHeaders(): Record<string, string>;
+    /**
+     * Record response headers and merge any `Set-Cookie` into the jar.
+     *
+     * undici's `Headers` exposes `getSetCookie()` (one entry per cookie);
+     * the DOM `Headers` type doesn't declare it, so cast structurally. In
+     * browsers neither `getSetCookie()` nor reading `set-cookie` is
+     * permitted, so `setCookies` is empty and the jar is left untouched.
+     */
+    private captureResponseMetadata;
+    /**
+     * Build a `Cookie` request header from the jar so non-browser callers
+     * stay pinned to the node holding their session. Returns `{}` when the
+     * jar is empty — always the case in browsers, leaving their native
+     * cookie handling untouched.
+     *
+     * `callerHeaders` is checked case-insensitively: if the caller already
+     * supplied a `Cookie`/`cookie` header, the jar yields to it entirely.
+     * (Object spread keys are case-sensitive, but `fetch`'s `Headers` are
+     * not — emitting `Cookie` here while the caller passed `cookie` would
+     * make the two coexist and get comma-combined instead of overridden.)
+     */
+    private cookieHeader;
     send(request: JsonRpcRequest, headers: Record<string, string>): Promise<JsonRpcResponse>;
     sendMultipart(request: JsonRpcRequest, headers: Record<string, string>, blob: Blob): Promise<JsonRpcResponse>;
 }