import type { ServerResponse } from "node:http";
import type { BgProcessInfo } from "./bg-process-manager.js";
/** Result shape produced by `BgProcessManager.waitForExit`. */
export type BgWaitResult = {
    info: BgProcessInfo;
    timedOut: boolean;
    aborted: boolean;
} | null;
/**
 * Stream the bg-process `wait` long-poll response.
 *
 * The long-poll can stay open for the full configurable wait timeout (default
 * 300s). The HTTP client (undici) enforces a default `headersTimeout` of ~300s
 * — if the server writes no bytes to the socket before that elapses, the
 * client throws `fetch failed`. The fix (mirroring the session `/wait`
 * endpoint) flushes headers immediately with `Transfer-Encoding: chunked` and
 * writes a heartbeat newline on `heartbeatMs` ticks while the wait is pending,
 * then ends with the final JSON payload.
 *
 * Header flush is LAZY — driven by the first heartbeat tick — rather than
 * eager. This is deliberate: `waitForExit` returns `null` synchronously (on the
 * first microtask) for an unknown process id, which resolves long before the
 * first heartbeat fires. By deferring the head until that first tick we can
 * still send a genuine `404` for the not-found case (no bytes written yet),
 * while a real pending wait flushes a `200`/chunked head on the first heartbeat
 * — well inside undici's ~300s `headersTimeout`, so it can never trip.
 */
export declare function streamBgWaitResponse(res: ServerResponse, waitForExit: () => Promise<BgWaitResult>, opts?: {
    heartbeatMs?: number;
}): Promise<void>;
//# sourceMappingURL=bg-wait-response.d.ts.map