The deterministic findings engine measures archive age using time.Since twice rather than the supplied Context's collection timestamp. An unchanged serialized Context can therefore produce a different decision and evidence age when recomputed later.
Reproduced on upstream 282ffe8fdd7acdd7b6e1dbd8cf04c155401d3a92: a fixed-epoch Context records a successful archive 30 minutes before collection, current positive WAL flow and a one-hour stall threshold. Calling the real findings.Compute later emits a critical stall with a many-day age instead of preserving the at-collection decision. Separate tests cover threshold and displayed-age boundaries.
I would like to correct this with one interval derived from Context.CollectedAt for both decision and evidence. Missing collection time remains unknown; it should not silently use the viewer's clock. Existing thresholds, managed-provider downgrades and explicit-failure handling remain unchanged.
Scope note: current offline diff/why commands do not themselves recompute the stored findings. The reproduction establishes the Compute contract, not a claim that merely opening a current CLI report re-evaluates it.
I rejected a separate proposed stats_reset fallback for never-successful archiving. PostgreSQL defines that field as the statistics reset time, not archiver enablement or continuous failure. Archiving works on completed WAL segments; a short current WAL sample cannot prove a historical eligible-segment backlog. The finding page now makes those evidence limits explicit.
Fixed-epoch regressions fail on base and pass with the correction. Twenty focused race repetitions, full affected package tests, committed-HEAD gate/six release builds and the full race suite pass. No SQL, dependencies, finding IDs or JSON shapes change.
The deterministic findings engine measures archive age using
time.Sincetwice rather than the supplied Context's collection timestamp. An unchanged serialized Context can therefore produce a different decision and evidence age when recomputed later.Reproduced on upstream
282ffe8fdd7acdd7b6e1dbd8cf04c155401d3a92: a fixed-epoch Context records a successful archive 30 minutes before collection, current positive WAL flow and a one-hour stall threshold. Calling the realfindings.Computelater emits a critical stall with a many-day age instead of preserving the at-collection decision. Separate tests cover threshold and displayed-age boundaries.I would like to correct this with one interval derived from
Context.CollectedAtfor both decision and evidence. Missing collection time remains unknown; it should not silently use the viewer's clock. Existing thresholds, managed-provider downgrades and explicit-failure handling remain unchanged.Scope note: current offline diff/why commands do not themselves recompute the stored findings. The reproduction establishes the Compute contract, not a claim that merely opening a current CLI report re-evaluates it.
I rejected a separate proposed
stats_resetfallback for never-successful archiving. PostgreSQL defines that field as the statistics reset time, not archiver enablement or continuous failure. Archiving works on completed WAL segments; a short current WAL sample cannot prove a historical eligible-segment backlog. The finding page now makes those evidence limits explicit.Fixed-epoch regressions fail on base and pass with the correction. Twenty focused race repetitions, full affected package tests, committed-HEAD gate/six release builds and the full race suite pass. No SQL, dependencies, finding IDs or JSON shapes change.