@essentialai/cogent-bridge/dist/services/wake-inflight.d.ts

Cogent Bridge — cross-agent comms for Claude Code, OpenAI Codex and Slack. Codex users: install with `curl -fsSL https://cogent.tools/install.sh | sh`, then start with `cogent-codex` for real-time peer wake.

/**
 * Hard ceiling on how long ANY marker may suppress rail C, whatever the writer stamped.
 * Bounds a corrupt/hostile/forgotten marker: worst case C is quiet for this long, then
 * resumes. MUST equal check-on-stop.mjs INFLIGHT_MAX_MS.
 */
export declare const INFLIGHT_MAX_MS = 1800000;
/** Multiplier over COGENT_TIMEOUT_MS covering primary + retry execRemote plus overhead. */
export declare const INFLIGHT_TIMEOUT_FACTOR = 3;
/**
 * How long a bridge whose MCP client is gone may keep draining a wake before it exits anyway.
 *
 * The SAME bound this file already gives a wake in flight: up to two execRemote runs (primary +
 * rotated-session retry) at COGENT_TIMEOUT_MS each, i.e. INFLIGHT_TIMEOUT_FACTOR × the timeout,
 * never more than INFLIGHT_MAX_MS. A shorter cap abandons a retried wake partway; an uncapped one
 * let a huge COGENT_TIMEOUT_MS (it has no maximum) keep an orphan alive indefinitely. The drained
 * bridge has already withdrawn its claim on the peer name, so the wait no longer blocks a restart.
 */
export declare function drainCapMs(timeoutMs: number): number;
/**
 * `~/.cogent/wake-inflight/<sha256(cwd)[..16]>.<peerId>.json`
 *
 * Deliberately homedir-based (see note 1). `cwd` defaults to the bridge's own process.cwd(),
 * which is what credential-store keys on and what the hook's `input.cwd` reports — using the
 * peer's *registered* cwd string instead would let a symlinked or sub-path registration
 * silently key the two processes differently.
 */
export declare function wakeInflightPath(peerId: string, cwd?: string): string;
/**
 * Announce that rail B is handling `messageId` for `peerId`.
 *
 * Called when the message is ACCEPTED (including when it is queued behind an in-progress
 * wake), not when the subprocess starts: a message sitting in B's queue is equally "about to
 * be answered by B", and rail C firing about it mid-capture corrupts the SAME turn — the
 * message-burst shape that Slack produces constantly.
 *
 * Synchronous on purpose: the marker's whole value is ordering — it must be on disk before
 * the agent's turn can end. Never throws; a marker we could not write degrades to today's
 * behaviour, never to a failed wake.
 */
export declare function markWakeInFlight(peerId: string, messageId: string, traceId?: string, cwd?: string): void;
/**
 * The wakes running RIGHT NOW for this peer — the "active wakes" view.
 *
 * Added for visibility (2026-09-04): an external report described a live worktree being
 * edited by wakes with no way to see that any were running. The markers already existed
 * for the rail-B/rail-C race; this only reads them. Expired entries are omitted rather
 * than reported as live — a leaked marker must not become a phantom "active wake".
 */
export declare function listWakeInFlight(peerId: string, cwd?: string): Array<{
    messageId: string;
    startedAt: number;
    expiresAt: number;
    traceId?: string;
}>;
/**
 * Retract the marker once the outcome is recorded (a captured reply OR a fail-loud notice).
 * Runs from a `finally` — a leaked marker is the one failure mode that would mute rail C.
 * Writes the pruned map back rather than unlinking, so a concurrent bridge's live entries
 * survive (see note 5).
 */
export declare function clearWakeInFlight(peerId: string, messageId: string, cwd?: string): void;
//# sourceMappingURL=wake-inflight.d.ts.map