import type { ApiClient } from './api-client';
/**
 * CloudWatch Alert 処理クラス
 * AppSync Push 受信時・フォールバック・定期ポーリングから呼ばれる
 */
export declare class AlertProcessor {
    private readonly client;
    private readonly tenantCode;
    private readonly projectCode;
    /**
     * 処理中の alertNumber を保持する重複ガード。
     * AppSync Push とポーリングが同時に同じアラートを処理しようとしたり、
     * 連続ポーリングで二重処理されるのを防ぐ。
     */
    private readonly inFlight;
    constructor(client: ApiClient, tenantCode: string, projectCode: string);
    /**
     * 単一アラームを処理する（AppSync Push・ポーリング両方から呼ばれる）
     * null になるケース: AppSync Push で alertNumber を受信したが、
     * DynamoDB Streams → RDS 同期がまだ完了していない場合（稀なタイミング問題）
     */
    processAlert(alertNumber: string): Promise<void>;
    /**
     * アラートを failed に遷移させる。更新自体が失敗した場合は握りつぶさず
     * logger.error で記録する（status は processing のまま残り、スタック救済
     * フロー recoverStaleProcessingAlerts の対象になる）。
     */
    private markFailed;
    /**
     * pending アラームを一括取得して処理する（フォールバック・定期ポーリング用）
     * getPendingAlerts は status=pending のみ取得する（processing は含めない）。
     * processing でスタックしたアラートの救済は recoverStaleProcessingAlerts で
     * 低頻度に別途行う（無限ループ防止のため通常ポーリングから分離）。
     */
    checkPendingAlerts(): Promise<void>;
    /**
     * 指定分数以上 processing のままスタックしたアラートを救済する。
     * 通常の高頻度ポーリング（checkPendingAlerts）とは分離した低頻度フローから
     * 呼ぶこと。これにより、processing で止まったアラートを毎回再処理して
     * CQRS コマンドが無限に増殖するのを防ぐ。
     *
     * @param staleProcessingMinutes この分数以上 processing のアラートを対象とする
     */
    recoverStaleProcessingAlerts(staleProcessingMinutes: number): Promise<void>;
}
/**
 * フォールバック用: チェックして alert-processor を更新する関数
 * agent-transport.ts の onReconnect から呼ばれる
 */
export declare function checkPendingAlerts(client: ApiClient, tenantCode: string, projectCode: string): Promise<void>;
//# sourceMappingURL=alert-processor.d.ts.map