/**
 * Default transient-tool-error classifier: true for a recognized MySQL/Postgres/SQLite
 * lock-contention shape (by driver `code`/`errno`/`sqlState`, or a matching message), checked on the
 * error itself and one level of `cause` (drivers commonly wrap the original error). A plain `Error`
 * with none of these markers — any other business failure — is `false`.
 */
export declare function isTransientToolError(error: unknown): boolean;
/** Total attempts (initial try + retries) when `toolTransientRetry` doesn't set `attempts`. */
export declare const DEFAULT_TOOL_TRANSIENT_RETRY_ATTEMPTS = 2;
/** Backoff base in ms — the wait between attempt N and N+1 is `backoffMs * N`. */
export declare const DEFAULT_TOOL_TRANSIENT_RETRY_BACKOFF_MS = 150;
/** The host-configurable policy — everything, including the (in-process) `classify` fn. */
export interface ToolTransientRetryOptions {
    /** Total attempts (initial try + retries). Defaults to {@link DEFAULT_TOOL_TRANSIENT_RETRY_ATTEMPTS}. */
    attempts?: number;
    /** Backoff base in ms. Defaults to {@link DEFAULT_TOOL_TRANSIENT_RETRY_BACKOFF_MS}. */
    backoffMs?: number;
    /** Overrides the default classifier — widen or narrow which errors are treated as transient. */
    classify?: (error: unknown) => boolean;
}
/** `false` disables transient retry entirely — a tool's own thrown error surfaces immediately. */
export type ToolTransientRetrySetting = ToolTransientRetryOptions | false;
export interface InvokeWithTransientRetryOptions {
    /**
     * Recognizes the runner's control-flow signals (durable suspend / continue-as-new) so a retry
     * never swallows one — same rule the loop's tool catch already applies. Undefined for a call site
     * with no such notion (e.g. the inline runner, which has no workflow ctx to suspend on).
     */
    isControlFlowError?: (error: unknown) => boolean;
    /**
     * Called before each wait-and-retry, with the 1-based ordinal of the attempt that just failed and
     * the error it threw. The call site uses this to emit the `tool.retry` diagnostics event —
     * `invokeWithTransientRetry` itself carries no tool identity (name/callId), only the thunk.
     */
    onRetry?: (attempt: number, error: unknown) => void;
}
/**
 * Retries `fn` in place — never a new durable step/checkpoint, just repeated attempts inside
 * whichever step body already wraps this call. `setting: false` runs `fn` once, unwrapped (no
 * classify/backoff bookkeeping at all). Otherwise: try; on a thrown error, rethrow immediately if
 * it's a recognized control-flow signal, else if the (possibly custom) classifier calls it transient
 * AND attempts remain, wait `backoffMs * attemptNumber` and retry; otherwise rethrow the error as-is.
 */
export declare function invokeWithTransientRetry<T>(fn: () => Promise<T>, setting: ToolTransientRetrySetting, options?: InvokeWithTransientRetryOptions): Promise<T>;
//# sourceMappingURL=tool-retry.d.ts.map