Trace-flag reads decide on the newest successful run's row count, so an ordinary run no longer hides every enabled flag (#3999 follow-up)

[erikdarlingdata]

Fixes a regression #4030 put on dev.

Why

#4030 (#3999) anchored the trace-flag display reads on the collector's newest successful run by comparing timestamps: show the newest capture only if MAX(trace_flags.capture_time) >= MAX(collection_log.collection_time) for the collector's SUCCESS rows.

The service stamps a collection_log row when the run ENDS (DarlingObservability.LogCollectionAsync uses DateTime.UtcNow at log time), after the run's capture rows. So after every ordinary run the newest SUCCESS is a few seconds newer than its own capture, and the comparison is false. Dev currently shows no trace flags on any server in get_trace_flags and the viewer's Configuration grid, even with flags on. #4030's test only seeded the all-off case, never an ordinary run in the service's real write order.

Lite stamps collection_log at run START, so the same SQL happened to hold there. No timestamp comparison means the same thing in both products.

What changes

• All three reads now keep the newest capture unless the newest SUCCESS wrote 0 rows: DarlingCurrentConfigReader.TraceFlagsSql (MCP), ViewerDataService.TraceFlagsSql (viewer) and LocalDataService.GetLatestTraceFlagsAsync (Lite).
• Every capture writes the full list of flags that are on (the shared TraceFlagsCollector returns its written row count in both products), so 0 means every flag was off.
• No SUCCESS row, or a NULL count from an old row, keeps the pre-fix reading.
• The newest SUCCESS is read with ORDER BY collection_time DESC NULLS LAST LIMIT 1, using the existing (server_id, collection_time) index. The trace-flags collector is daily, so the walk back is at most a day of that server's log.

Test plan

• TraceFlags_AnswerForTheNewestSuccessfulRun_AgainstDevPostgres (replaces Trace-flag display reads anchor on the collector's newest successful run (#3999) #4030's all-off test) is seeded in the service's real write order: the capture, then a log row stamped 3 s later. It covers 1117 on, then all off, then a failed run (the answer stays none), then 4199 on. It runs the viewer and MCP readers and asserts they agree. Live on PG 18.6 + TimescaleDB 2.30.1: ViewerConfigurationSqlTests + ViewerConfigurationLivePostgresTests 17/17, none skipped.
• Red-watch: with Trace-flag display reads anchor on the collector's newest successful run (#3999) #4030's SQL restored, step 1 fails with Expected: [1117], Actual: [], the regression exactly.
• New Lite twin TraceFlagsLatestRunTests, seeded in Lite's order (log stamped at start): the same four steps, plus no run record keeping the capture. 2/2.
• Darling.Tests and Lite.Tests build with 0 warnings.
• No CHANGELOG entry of its own: Trace-flag display reads anchor on the collector's newest successful run (#3999) #4030's entry describes the intended behaviour, which this makes true.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GdmA4ND1wLSqA91ax1m4xv