namespace ZB.MOM.WW.ScadaBridge.HealthMonitoring;

public class HealthMonitoringOptions
{
    /// <summary>Interval at which sites emit health reports to the central cluster.</summary>
    public TimeSpan ReportInterval { get; set; } = TimeSpan.FromSeconds(30);
    /// <summary>Duration of silence after which a site is classified as offline.</summary>
    public TimeSpan OfflineTimeout { get; set; } = TimeSpan.FromMinutes(1);

    /// <summary>
    /// Offline timeout applied to the synthetic "central" site only. Real sites
    /// emit frequent heartbeats that keep <c>LastHeartbeatAt</c> fresh, so the
    /// normal <see cref="OfflineTimeout"/> only fires on genuine total loss. The
    /// "central" self-report has no heartbeat source — its only signal is the
    /// 30s <see cref="CentralHealthReportLoop"/>, so a single skipped/late
    /// self-report (leader GC pause, brief stall, mid-failover before the new
    /// leader's loop spins up) would flap it offline under the 60s site timeout.
    /// A longer central grace gives the equivalent of "one missed report" that
    /// the design doc grants real sites. Default: 3x the report interval.
    /// </summary>
    public TimeSpan CentralOfflineTimeout { get; set; } = TimeSpan.FromMinutes(3);

    /// <summary>
    /// Duration an online site may go without a full health <em>report</em>
    /// (heartbeats notwithstanding) before it is flagged
    /// <see cref="SiteHealthState.IsMetricsStale"/>. Distinct from
    /// <see cref="OfflineTimeout"/>, which is heartbeat-based liveness: a site
    /// whose HealthReportSender has died keeps heartbeating and stays "online",
    /// but its metrics freeze — this window surfaces that. Must be positive and
    /// no shorter than <see cref="ReportInterval"/> (a window shorter than one
    /// report interval would flag every healthy site). Default: 2 minutes
    /// (~4 missed 30s reports).
    /// </summary>
    public TimeSpan MetricsStaleTimeout { get; set; } = TimeSpan.FromMinutes(2);

    /// <summary>
    /// Unacked LocalDb replication oplog depth above which a site is considered backlogged
    /// (register row 33). Crossing this alone shows nothing — the backlog must also stay
    /// above it for <see cref="LocalDbBacklogSustainedFor"/> before the Health dashboard
    /// badges the site. Must be positive. Default: <c>1000</c> entries.
    /// </summary>
    public long LocalDbBacklogThreshold { get; set; } = 1000;

    /// <summary>
    /// How long the oplog backlog must stay continuously above
    /// <see cref="LocalDbBacklogThreshold"/> before the Health dashboard badges the site
    /// (register row 33).
    /// </summary>
    /// <remarks>
    /// This dwell time is the whole point of the signal, not a refinement of it. A bare
    /// threshold would fire every single day on a healthy replicated site: the `site_events`
    /// retention purge and the storage-cap trim are CDC-captured like any other write, so the
    /// backlog jumps by the deleted batch size and then drains as the peer acks it. That spike
    /// is expected and documented (see <c>docs/deployment/topology-guide.md</c> → *Reading the
    /// replication backlog*). Healthy means the backlog RETURNS TO ~0; unhealthy means it
    /// stays up. Only a sustained window can tell those apart, so the default is set well
    /// clear of a purge drain. Must be positive and no shorter than
    /// <see cref="ReportInterval"/> — a window shorter than one report interval could be
    /// satisfied by a single sample, which is exactly the bare threshold this exists to avoid.
    /// Default: 15 minutes.
    /// </remarks>
    public TimeSpan LocalDbBacklogSustainedFor { get; set; } = TimeSpan.FromMinutes(15);
}