namespace ZB.MOM.WW.ScadaBridge.AuditLog.Site.Telemetry;

/// <summary>
/// Tuning knobs for the site-side <see cref="SiteAuditTelemetryActor"/> drain
/// loop. Defaults: drain every 5 s while rows are
/// flowing (busy), every 30 s when the queue is empty (idle).
/// </summary>
public sealed class SiteAuditTelemetryOptions
{
    /// <summary>
    /// Maximum number of <see cref="ZB.MOM.WW.ScadaBridge.Commons.Entities.Audit.AuditEvent"/>
    /// rows read from the site SQLite queue and pushed in a single gRPC batch.
    /// </summary>
    public int BatchSize { get; set; } = 256;

    /// <summary>
    /// Delay between drains when the previous drain found at least one Pending
    /// row OR the previous push faulted. Re-drain quickly to keep telemetry
    /// flowing and to retry transient gRPC errors.
    /// </summary>
    public int BusyIntervalSeconds { get; set; } = 5;

    /// <summary>
    /// Delay between drains when the previous drain found no Pending rows.
    /// Longer interval avoids hammering an idle SQLite + gRPC channel.
    /// </summary>
    public int IdleIntervalSeconds { get; set; } = 30;

    /// <summary>
    /// How long a cached-telemetry audit row may go without a resolvable
    /// <c>OperationTracking</c> snapshot before the drain ABANDONS its
    /// operational half and marks the row Forwarded. Default: 300 s.
    /// </summary>
    /// <remarks>
    /// <para>
    /// A missing tracking snapshot is normally a brief write race — the audit
    /// row lands microseconds before the tracking row — so the drain retries
    /// within this grace period. Past it the snapshot is almost certainly gone
    /// for good (tracking retention elapsed while central was unreachable, or
    /// the two stores were reset independently), and retrying forever is
    /// actively harmful: the queue is read oldest-first with a fixed
    /// <see cref="BatchSize"/>, so a batch's worth of permanently-unresolvable
    /// rows at the head STARVES every newer cached row behind them.
    /// </para>
    /// <para>
    /// Abandoning costs only the operational (<c>SiteCalls</c>) half, which is
    /// unrecoverable anyway once the tracking row is gone. The audit half is
    /// NOT lost: the reconciliation pull covers Forwarded rows as well as
    /// Pending ones, and central dedups on EventId.
    /// </para>
    /// <para>
    /// Set to 0 to abandon on the first failed lookup. Negative values are
    /// treated as 0.
    /// </para>
    /// </remarks>
    public int CachedTrackingGraceSeconds { get; set; } = 300;
}
