/**
 * CMS retry helper for orchestration activities.
 *
 * Two policies:
 *
 * - `cmsRetryCritical`: 4 retries at 1s / 5s / 15s / 90s (5 total attempts).
 *   The first three handle transient blips (connection reset, deadlock,
 *   serialization failure, brief unavailability). The 90s tail handles
 *   PostgreSQL maintenance windows (failover, restart, connection storm).
 *   On exhaustion or non-transient error, the original error is thrown so
 *   the orchestration's own classification still works.
 *
 * - `cmsRetryBestEffort`: 1 retry at 3s (2 total attempts).
 *   For non-flow-critical writes (event log entries, etc.). On exhaustion or
 *   non-transient error, logs and returns `undefined` instead of throwing.
 *   Callers that don't care about the return value can ignore it.
 *
 * Only PostgreSQL transient errors trigger a retry. Constraint violations,
 * syntax errors, and other deterministic failures propagate immediately —
 * retrying those just delays the inevitable.
 */
/**
 * Returns true if `err` looks like a retryable PG transient.
 *
 * If the error has a structured `code`, the code is the verdict — we do not
 * fall through to the message regex. Otherwise a non-transient SQLSTATE (e.g.
 * a constraint violation whose message happens to contain "connection") would
 * be retried.
 *
 * The message-only patterns are deliberately tight. Broader matchers (e.g.
 * "connection closed", "client has encountered a connection error") catch
 * natural pool teardown during normal shutdown — retrying against a
 * deliberately-closed pool just delays the inevitable.
 */
export declare function isTransientCmsError(err: unknown): boolean;
export declare function cmsRetryCritical<T>(label: string, fn: () => Promise<T>, log?: (msg: string) => void): Promise<T>;
export declare function cmsRetryBestEffort<T>(label: string, fn: () => Promise<T>, log?: (msg: string) => void): Promise<T | undefined>;
//# sourceMappingURL=cms-retry.d.ts.map