Skip to content

State what the refresh-slot routine-band case establishes, in the present tense - #3181

Merged
erikdarlingdata merged 2 commits into
devfrom
fix/refresh-slot-case-present-tense
Sep 8, 2026
Merged

State what the refresh-slot routine-band case establishes, in the present tense#3181
erikdarlingdata merged 2 commits into
devfrom
fix/refresh-slot-case-present-tense

Conversation

@erikdarlingdata

Copy link
Copy Markdown
Owner

Comment-only change in TimescaleSupportTests.cs. The assertion and the value it is fed are untouchedgit diff is nine lines added, seven removed, all inside one block comment.

What was wrong

The comment above the routine-band case in TheRefreshSlotLogLine_IsLeveledByBand_AndSaysNothingWithoutAReading narrated a failure:

THE ROUTINE-BAND CASE IS FED THE RECORDED CEILING, and after #3166's census re-derivation that reading logs Warning rather than Debug — so this assertion FAILS and is left exactly as written. … The remedy is the slot or the fraction (#3035, #3044, #3107).

Both factual claims are false on the current grid, and the assertion below it passes. That also makes the comment a history-of-a-change note rather than a statement of what the code does, which is what the repo's comment convention rules out.

What is true, measured rather than reasoned

Evaluated by compiling PerformanceMonitor.Darling.Storage (plain net10.0) and reading the real derivation chain through reflection, rather than hand-computing it:

value
HeaviestHourlyRefreshObservedCeilingSeconds 896
HeaviestRefreshWindowMinutes 21
RefreshPhaseSlotSeconds 1,260
RefreshSlotWarningSeconds 1,050
ClassifyRefreshSlotHeadroom(896) InsideSlot
ClassifyRefreshSlotHeadroom(1050) ApproachingSlot
ClassifyRefreshSlotHeadroom(1260) SlotExceeded

InsideSlot falls to LogHeaviestRefreshSlotHeadroom's default: arm, which is LogDebug. So the case establishes that the grid's own sizing figure is a routine reading — 71.1% of the slot, 154 s below the watch line.

#3178 is what changed it: the slot went to 1,260 s and the watch line to 1,050 s, and #3178's own red-tests table already records the outcome ("the line at the ceiling is Debug:").

What the replacement keeps

The stale comment's reasoning was right and is preserved: re-pointing the case at an arbitrary lower literal would keep the level table covered while dropping the claim worth holding — that the figure the grid is sized around is routine, not a warning. The replacement states that in the present tense and adds why it stays true without maintenance: both sides are read from TimescaleSupport rather than written as literals here, so the ceiling and the watch line can only meet through a real change (a census that raises the ceiling, a re-derivation that narrows the slot), and when they do this case goes red rather than the product quietly calling its own sizing figure a warning.

Verification

Darling.Tests targets net10.0-windows and cannot run on macOS, so the shipped TimescaleSupportTests.cs was compiled unmodified — with its real helpers CapturingTestLogger, LiveStoreCleanup, LiveCleanupBatch, IlCallSiteScanner — into a net10.0 xunit.v3 harness named Darling.Tests so InternalsVisibleTo still applies.

48 total, 0 failed, 0 errors, 15 skipped, 0 not run. Every skip is live-Postgres gated (DARLING_TEST_PG). The target case is absent from all 15 [SKIP] lines, so it ran rather than being counted as covered.

Red-proofed. With the fed value mutated from HeaviestHourlyRefreshObservedCeilingSeconds to RefreshSlotWarningSeconds, the case fails with Assert.StartsWith() Failure: String start does not match / String: "Warning: TimescaleDB: query_store_stats_interval_h"··· — so the Debug assertion discriminates and does not pass vacuously. Mutation confirmed present in the tree by git diff --numstat plus a content check before running, and confirmed restored by content afterwards, with CRLF endings intact (3,819 CRLF, 0 bare LF, no BOM).

dotnet build Darling/Darling.Tests/Darling.Tests.csproj -p:EnableWindowsTargeting=true succeeds, 0 errors.

CHANGELOG entry text (not committed)

Under [Unreleased]Fixed:

…sent tense

The comment above the InsideSlot case narrated a failure that no longer exists: it
said the recorded ceiling logs Warning rather than Debug and that the assertion
below it fails. Both are false on the current grid, and the assertion passes.

The ceiling is 896 s against a 1,260 s slot and a 1,050 s watch line, so
ClassifyRefreshSlotHeadroom bands it InsideSlot and LogHeaviestRefreshSlotHeadroom
takes the Debug arm. The replacement states that, and keeps the reason the case is
fed the grid's own sizing figure rather than a lower literal: both sides are read
from TimescaleSupport, so the case goes red if a census raises the ceiling or a
re-derivation narrows the slot until the product would call its own sizing figure
a warning.

The assertion and the value it is fed are unchanged.
Comment thread Darling/Darling.Tests/TimescaleSupportTests.cs Outdated
@claude

claude Bot commented Sep 8, 2026

Copy link
Copy Markdown

Reviewed. This is a genuinely comment-only change to Darling/Darling.Tests/TimescaleSupportTests.cs — the assertion and its fed value are untouched, confirmed via diff and by checking the assertion body still reads TimescaleSupport.HeaviestHourlyRefreshObservedCeilingSeconds unchanged.

Correctness of the new comment's claims — verified against PerformanceMonitor.Darling.Storage/TimescaleSupport.cs:

  • HeaviestHourlyRefreshObservedCeilingSeconds = 896 (const, line 2131)
  • RefreshPhaseSlotSeconds = HeaviestRefreshWindowMinutes * 60 → 21 × 60 = 1,260
  • RefreshSlotWarningSeconds = RefreshPhaseSlotSeconds * 5 / 6 → 1,260 × 5/6 = 1,050
  • 896 < 1,050 < 1,260, so ClassifyRefreshSlotHeadroom(896) bands InsideSlot, which falls to LogHeaviestRefreshSlotHeadroom's default: (Debug) — matching the Assert.StartsWith("Debug:", ...) a few lines below.
  • 896 / 1,260 = 71.1%, and 1,050 − 896 = 154 s — both figures in the new comment check out.

So the replacement comment is factually accurate and no longer narrates a since-resolved failure (the old comment's claim that this assertion FAILS is false against current values, as the PR description documents). This isn't a T-SQL change and there's no Lite counterpart to this file (TimescaleDB continuous-aggregate refresh scheduling is Darling/Postgres-specific; Lite has no equivalent), so parity isn't a concern here.

Left one inline nit: the new comment doesn't cite an issue number, which is otherwise consistent practice in this file and is called out explicitly in CONTRIBUTING.md's comment-style guidance.

No correctness, security, or performance concerns — this is test-file documentation only, nothing here touches runtime code paths.

CONTRIBUTING.md's comment convention asks for issue numbers alongside the
measurements. #3178 sets all three figures; #3166 is how a census raises the
ceiling and #3174/#3178 how a re-derivation narrows the slot, which are the two
changes that would turn this case red.
@claude

claude Bot commented Sep 8, 2026

Copy link
Copy Markdown

Reviewed. This is a comment-only change in Darling/Darling.Tests/TimescaleSupportTests.cs — no code, T-SQL, or Lite/Darling parity surface touched (Darling-only test file; there's no Lite counterpart to check for drift).

Verified the new comment's factual claims against the current TimescaleSupport.cs:

  • HeaviestHourlyRefreshObservedCeilingSeconds = 896 (const)
  • HeaviestRefreshWindowMinutes = 21 → RefreshPhaseSlotSeconds = 1,260
  • RefreshSlotWarningSeconds = 1260 * 5/6 = 1,050
  • 896/1260 = 71.1%, 1050-896 = 154 — both match the comment
  • ClassifyRefreshSlotHeadroom(896) bands InsideSlot (< 1050), so the fed value does produce the asserted Debug: line

The replacement is accurate, present-tense, and no longer narrates a historical failure (consistent with the repo's comment convention). No correctness, security, or performance concerns — nothing to flag.

@erikdarlingdata
erikdarlingdata merged commit a203363 into dev Sep 8, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant