An alert-pass read outside AlertPassCommandTimeoutTests' six-file allowlist is untimed, and the pin cannot see it #2932

An alert-pass store read sits outside AlertPassCommandTimeoutTests' six-file allowlist, so it is untimed and the pin is structurally unable to say so

Found by #2874's group B and verified independently on current dev. Two halves, filed together on purpose: fixing the site alone leaves the next one just as invisible.

The untimed site

Darling/PerformanceMonitor.Darling.Service/DarlingWorker.cs:3886, ReadLatestCpuAsync:

:3891    await using var connection = await _postgres!.OpenConnectionAsync(cancellationToken);
:3892    using var command = new NpgsqlCommand(@"
             SELECT sqlserver_cpu_utilization, other_process_cpu_utilization
             FROM cpu_utilization_stats
             WHERE server_id = $1
             ORDER BY sample_time DESC
             LIMIT 1", connection);

No CommandTimeout, so it inherits Npgsql's undocumented 30 s default — the defect class #2874 exists to sweep.

It is unambiguously an alert-pass read: its single caller is :2921, which feeds the result straight into the AlertServerSnapshot passed to engine.EvaluateServerAsync on the next line.

Why #2882's pin reports clean over it

Darling/Darling.Tests/AlertPassCommandTimeoutTests.cs:55 scopes the whole scan to an allowlist of six filenames:

DarlingAlertReadAdapter.cs, DarlingPostgresAlertReadAdapter.cs, PgAlertStateStore.cs,
PgMuteRuleStore.cs, PgAlertHistoryStore.cs, DarlingSelfAlertEvaluator.cs

DarlingWorker.cs is not among them, so the site is never read.

The pin already guards the direction that doesn't matter here. It asserts each of the six paths resolves, with a comment saying a renamed or moved alert-pass type must fail loudly "rather than silently shrinking the scan to the files that still resolve — an empty or partial sweep is how a guard starts reporting clean on code it no longer reads." That reasoning is right and the guard works: it catches a file leaving the list. There is nothing at all against a site that was never in it, which is the asymmetry that let this through.

Why an allowlist of filenames is the wrong scope, specifically

Group B established the general rule the hard way, twice in one PR, from opposite directions: .Service's budget regimes do not respect file boundaries. It over-counted by attributing sites to a regime by file, and it under-counted by excluding DarlingObservability.WriteAnalysisStateAsync because that site sits lexically inside a budgeted method while receiving the plain stoppingToken rather than the budgeted one. The reliable test is:

which cancellation token does this call site actually receive, and what re-runs it?

A filename allowlist encodes precisely the assumption that failed both times. DarlingWorker.cs is the clearest case in the project — it holds sites belonging to the startup regime, the sweep body, the analysis pass and the alert pass all at once.

Shape of the fix

Both halves, in one change:

1. Give the site a deadline. It plausibly takes the alert pass's existing 10 s, but that number was derived from a 30 s interval and a 1,744.9 ms read, and this is a different query — a single-row ORDER BY … LIMIT 1 against cpu_utilization_stats. Confirm the derivation rather than inheriting the constant by proximity.
2. Re-scope the pin so the next one cannot hide. Either derive the scan scope from the pass's actual call graph instead of a filename list, or keep the list and add a control that fails when an alert-pass store read exists outside it. The second is cheaper and is the one that would have caught this; the first is what stops the class.

Whatever lands, the pin needs a red-first proof that it fails on this site being untimed — a widened scope that still can't see DarlingWorker.cs would pass while guarding nothing, which is the same trap in a new coat.

Not verified

The site's real-world duration was not measured; there is no reported failure attached to it. cpu_utilization_stats is a hypertable and the query is a single-row read on a covered ordering, so the expectation is that it is fast and that this is latent exposure rather than an active problem — stated as an expectation, not a measurement.