Part of #2936

Darling/PerformanceMonitor.Darling.Service/DarlingWorker.cs

@@ -1072,10 +1072,11 @@
            instance holding the migration advisory lock both succeed seconds later; a rung that cannot
            apply against this store never will. StartupFailureTriage decides which arrived and carries
            the reasoning for where that boundary sits, including why anything it cannot place positively
-           stays terminal. This block is the ONLY step of the collection loop's start that kills collection,
-           so the degrade-vs-kill question the next block answers out loud is answered here too: a
-           transient store failure now degrades to a delayed first cycle, and everything else keeps the
-           critical line and the stand-down byte for byte. Both caps are load-bearing: an attempt is not
+           stays terminal. This is the LAST of the three startup steps that can kill collection — the config
+           load and the managed bootstrap above are the other two, triaged the same way through the same
+           predicate — so the degrade-vs-kill question the next block answers out loud is answered here
+           too: a transient store failure now degrades to a delayed first cycle, and everything else keeps
+           the critical line and the stand-down byte for byte. Both caps are load-bearing: an attempt is not
            quick just because a refused connect is — one that blocks behind a peer's advisory lock can
            spend MigrationLockWaitTimeoutSeconds — so the wall-clock budget is what stops 25 attempts from
            becoming ten hours, and the attempt count is what the warning line reports.
@@ -2661,11 +2662,11 @@
            The baseline advances only on SUCCESS, so a failed attempt retries on the next reload rather
            than being recorded as applied. */
         if (_postgres is not null
             && DarlingManagedRoles.ShouldReassertComposeStatementTimeout(
                 view.ComposeStatementTimeoutSeconds, _appliedComposeStatementTimeoutSeconds,
                 config.Postgres.Managed, OperatingSystem.IsWindows()))
         {
             if (await DarlingManagedRoles.ReassertComposeStatementTimeoutAsync(
                     _postgres, view.ComposeStatementTimeoutSeconds, _logger, cancellationToken))
             {
                 _appliedComposeStatementTimeoutSeconds = view.ComposeStatementTimeoutSeconds;

Darling/PerformanceMonitor.Darling.Service/StartupFailureTriage.cs

@@ -157,8 +157,9 @@ namespace PerformanceMonitor.Darling.Service;
 internal static class StartupFailureTriage
 {
     /// <summary>
-    /// How many times the collection loop's first store interaction may be tried before a failure
-    /// <see cref="IsRetryable"/> accepts becomes terminal anyway.
+    /// How many times any ONE of the three triaged startup steps may be tried before a failure
+    /// <see cref="IsRetryable"/> accepts becomes terminal anyway. Shared by all three, each of which keeps
+    /// its own stopwatch, so the count is per site and not a budget they draw down together.
     ///
     /// <para>Paired with <see cref="RetryBudget"/>, which is the real bound — see that constant
     /// for why an attempt cap alone is not one. Twenty-five tries <see cref="RetryDelay"/> apart is
@@ -260,7 +261,9 @@ internal static class StartupFailureTriage
     };
 
     /// <summary>
-    /// Whether the collection loop's first store interaction should be tried again after this failure.
+    /// Whether the triaged startup step that raised this should be tried again. One predicate for all
+    /// three sites — see the class remarks for why, and for the single typed carve-out that is the only
+    /// place they differ.
     /// FALSE for anything not positively recognised, including every <see cref="PostgresException"/> whose
     /// <c>SqlState</c> is not in <see cref="s_retryableSqlStates"/> — see the class remarks for why the
     /// unclassifiable case is terminal rather than retried.