import type { PersistedPendingEventWait, RunEventEnvelope } from "./types.js";
/**
 * Append a detached event-wait record and retain a bounded history.
 *
 * Retention is state-aware for the same reason approval retention is: a wait a
 * run is still parked on must never be evicted, because nothing could then
 * deliver its event or expire it and the run would wait forever. At the bound
 * the oldest finalized record is evicted first. A resolved record with an
 * unfinished claim remains reserved. When there are not enough finalized
 * records to make room, the append is rejected without changing existing
 * history.
 */
export declare function appendRetainedPendingEventWait(waits: PersistedPendingEventWait[], wait: PersistedPendingEventWait): void;
/**
 * Append one event to a run's bounded mailbox, refusing the append at the bound.
 *
 * Every entry in a mailbox is unconsumed by definition: an event is removed the
 * moment a wait takes it. So no entry is safe to evict. Dropping the oldest
 * would silently discard an event published before its node parked, which is
 * the case the mailbox exists to serve, and would leave the run parked forever
 * on a wait whose event was accepted. Claimed envelopes still reserve their
 * original slots because rollback must be able to reinsert them. The publish
 * is refused instead, loudly, the way the event-wait list refuses rather than
 * dropping a pending wait.
 */
export declare function appendRetainedRunEvent(mailbox: RunEventEnvelope[], event: RunEventEnvelope, reservedEntries?: number): void;
/**
 * Remove and return the oldest buffered event with this name.
 *
 * Callers must treat this as the point where the event is consumed: it is
 * removed from the mailbox, so a caller that then fails to deliver it has to
 * put it back.
 */
export declare function takeRetainedRunEvent(mailbox: RunEventEnvelope[], eventName: string, publishedBefore?: Date): RunEventEnvelope | null;
/**
 * Return a claimed event to its publication-order position after delivery failed.
 *
 * Concurrent claims can roll back in either order. Unconditionally prepending
 * each event would reverse two claims restored A-then-B into B,A, so insert by
 * the backend publication sequence (falling back to the durable timestamp)
 * instead. No bound is enforced here on purpose: the event already held a
 * place in this mailbox when it was claimed, and refusing the restore would
 * lose an event that was durably accepted.
 */
export declare function restoreRetainedRunEvent(mailbox: RunEventEnvelope[], event: RunEventEnvelope): void;
//# sourceMappingURL=event-wait-retention.d.ts.map