/**
 * daemon/todoist-pending.ts — a reminder or comment whose parent task could not
 * be resolved yet is not gone, it is waiting.
 *
 * Resolving `reminder:fired`/`note:added` means one Todoist API call
 * (`fetchParentTask`) on the daemon's own event loop. A busy loop or a flaky
 * network turns that call into "fetch failed" for reasons that have nothing to
 * do with whether the task exists — see audit ab-mudmf06z, a reminder dropped
 * with exactly that message while the event loop was blocked (fixed in
 * 0.58.1). Treating that the same as "no such task" loses a real event.
 *
 * So a transient failure is queued here instead of dropped, and outlives both
 * the inline backoff in todoist-webhook.ts and a daemon restart: the sweep
 * that drains this file runs once shortly after `startTodoistWebhook` and
 * again on every tick after that.
 */
import type { TodoistEvent } from "./todoist-webhook.js";
export interface PendingEvent {
    /** `eventKey()` of the original event — dedupes queueing and drives removal. */
    key: string;
    event: TodoistEvent;
    kind: "reminder" | "comment";
    parentId: string;
    firstSeenAt: string;
    attempts: number;
    lastError: string;
}
export declare function listPendingEvents(): PendingEvent[];
/** No-op if `key` is already queued — the sweep will retry it regardless. */
export declare function queuePendingEvent(p: {
    key: string;
    event: TodoistEvent;
    kind: "reminder" | "comment";
    parentId: string;
    lastError: string;
}): void;
export declare function removePendingEvent(key: string): void;
export declare function bumpPendingEvent(key: string, error: string): void;
/**
 * Older than this, a pending event is not "waiting for the network to recover"
 * — nothing here is expected to be down for a day. Giving up keeps the queue
 * from becoming a second, invisible audit log.
 */
export declare const PENDING_MAX_AGE_MS: number;
//# sourceMappingURL=todoist-pending.d.ts.map