release/1.0 went red at 00:00 on 2026-09-01, on a commit nobody had touched.
What broke
Controller.checks() read the capacity-tariff peak with self.peak.peak() - no argument - so tariff.py:410 resolved the month as month_key(datetime.now(timezone.utc)). test_tariff.py section 10 banks its quarter at the fixed fixture B = 2026-08-30. From 1 September the status page was correctly asked for September, correctly answered NO_RECORD, and explain() returned "2026-09: no completed quarter recorded yet" - a string containing no "peak", which the section's filter at line 867 requires. It matched nothing, printed status row: (none), and four checks failed.
Isolated by holding the commit and the image constant and moving only the clock, under libfaketime in .gitea/ci's own image:
faked clock
result
2026-08-30
all checks passed
2026-09-01
4 FAILED
It fails identically at f4914a1, 04292c4~1 and 04292c4. The calendar, not a regression. Latent since TARIFF-01 merged on 2026-08-30; every PR that ever ran this suite ran it in August, so CI was legitimately green each time.
What this changes
The product is right and the test was wrong, so the live page is untouched. Section 5 of this same file calls NO_RECORD"a normal state on the 1st of the month", and a capacity tariff is billed monthly, so a page showing the current month is correct.
checks() takes when: datetime | None = None and threads it into peak() and warning_frac(). This follows the existing convention rather than inventing one - PeakStore.peak(), PeakTracker.peak(), headroom_w() and warning_frac() all already take exactly that parameter. The single production caller (status_payload(), main.py:1469) passes nothing and still means today.
Why it cannot silently come back
Three new checks, none of which a clock can satisfy:
the same controller read at two different reference months must produce two different rows;
the later month must read NO_RECORD, distinguishable from both an observed peak and an unreadable store;
checks() with no argument must still mean today.
Verified by mutation: a checks() that drops when is red at every clock tried, where the old section went green in August.
Worth knowing during review - the first draft of these checks reproduced the bug. It selected rows on "peak", which the NO_RECORD row does not contain, so it dropped the row and then graded its absence. They select on "quarter(s) banked" instead. That is the pickup.md pattern "a reading that failed to observe anything gets treated as an observation", hit while fixing an instance of it.
Verification
Full suite green, 15 files, in .gitea/ci's image at the real clock and at faked clocks in 2026-08, 2026-12, 2027-02 and 2027-03 - which is also the evidence that no other suite carries a fixed-date fixture graded against datetime.now().
One thing left alone deliberately
Only the UNREADABLE branch prefixes its row with capacity-tariff peak:. The NO_RECORD row carries neither that phrase nor the word peak. That asymmetry is what made the original filter brittle and what broke the first draft above. It is product text with other suites reading it, so it is reported here rather than changed - say the word and it can be a follow-up card.
Closes **TEST-17**.
`release/1.0` went red at 00:00 on 2026-09-01, on a commit nobody had touched.
## What broke
`Controller.checks()` read the capacity-tariff peak with `self.peak.peak()` - **no argument** - so `tariff.py:410` resolved the month as `month_key(datetime.now(timezone.utc))`. `test_tariff.py` section 10 banks its quarter at the fixed fixture `B = 2026-08-30`. From 1 September the status page was correctly asked for September, correctly answered `NO_RECORD`, and `explain()` returned `"2026-09: no completed quarter recorded yet"` - a string containing no `"peak"`, which the section's filter at line 867 requires. It matched nothing, printed `status row: (none)`, and four checks failed.
Isolated by holding the commit and the image constant and moving **only the clock**, under `libfaketime` in `.gitea/ci`'s own image:
| faked clock | result |
|---|---|
| 2026-08-30 | `all checks passed` |
| 2026-09-01 | `4 FAILED` |
It fails identically at `f4914a1`, `04292c4~1` and `04292c4`. The calendar, not a regression. Latent since TARIFF-01 merged on 2026-08-30; every PR that ever ran this suite ran it in August, so CI was legitimately green each time.
## What this changes
**The product is right and the test was wrong**, so the live page is untouched. Section 5 of this same file calls `NO_RECORD` *"a normal state on the 1st of the month"*, and a capacity tariff is billed monthly, so a page showing the current month is correct.
`checks()` takes `when: datetime | None = None` and threads it into `peak()` and `warning_frac()`. This follows the existing convention rather than inventing one - `PeakStore.peak()`, `PeakTracker.peak()`, `headroom_w()` and `warning_frac()` all already take exactly that parameter. The single production caller (`status_payload()`, `main.py:1469`) passes nothing and still means today.
## Why it cannot silently come back
Three new checks, none of which a clock can satisfy:
1. the same controller read at **two different reference months** must produce two different rows;
2. the later month must read `NO_RECORD`, distinguishable from both an observed peak and an unreadable store;
3. `checks()` with no argument must still mean today.
Verified by mutation: a `checks()` that drops `when` is **red at every clock tried**, where the old section went green in August.
Worth knowing during review - **the first draft of these checks reproduced the bug**. It selected rows on `"peak"`, which the `NO_RECORD` row does not contain, so it dropped the row and then graded its absence. They select on `"quarter(s) banked"` instead. That is the `pickup.md` pattern *"a reading that failed to observe anything gets treated as an observation"*, hit while fixing an instance of it.
## Verification
Full suite green, **15 files**, in `.gitea/ci`'s image at the real clock and at faked clocks in 2026-08, 2026-12, 2027-02 and 2027-03 - which is also the evidence that no *other* suite carries a fixed-date fixture graded against `datetime.now()`.
## One thing left alone deliberately
Only the `UNREADABLE` branch prefixes its row with `capacity-tariff peak:`. The `NO_RECORD` row carries neither that phrase nor the word `peak`. That asymmetry is what made the original filter brittle and what broke the first draft above. It is product text with other suites reading it, so it is reported here rather than changed - say the word and it can be a follow-up card.
release/1.0 went red at 00:00 on 2026-09-01 on a commit nobody had
touched. `Controller.checks()` read the capacity-tariff peak with
`self.peak.peak()` - no argument - so tariff.py resolved the month from
`datetime.now()`, while test_tariff.py section 10 banks its quarter at
the fixed fixture 2026-08-30. From 1 September the page was correctly
asked for September, correctly answered NO_RECORD, and the row read "no
completed quarter recorded yet" - a string containing no "peak", which
the section's own filter required. Four checks failed.
ISOLATED BY MOVING ONLY THE CLOCK. Same commit, same shipped-deps image,
libfaketime: green at 2026-08-30, four failures at 2026-09-01. Identical
at f4914a1, 04292c4~1 and 04292c4, so this is the calendar and not a
regression. It has been latent since TARIFF-01 merged on 2026-08-30, and
every PR that ever ran this suite ran it in August.
THE PRODUCT IS RIGHT AND THE TEST WAS WRONG, so the live page is
unchanged. Section 5 of this same file calls NO_RECORD "a normal state
on the 1st of the month" and a capacity tariff is billed monthly, so a
page showing the current month is correct. `checks()` now takes
`when: datetime | None = None` and threads it into peak() and
warning_frac() - the convention PeakStore.peak(), PeakTracker.peak(),
headroom_w() and warning_frac() all already follow. The one production
caller passes nothing and still means today.
AND THE DEFECT IS NOW DETECTABLE RATHER THAN SEASONAL. Three checks:
the same controller read at two different reference months must produce
two different rows, which no clock can satisfy; the later month must
read NO_RECORD and stay distinguishable from both an observed peak and
an unreadable store; and checks() with no argument must still mean
today. Verified by mutation - a checks() that drops `when` is red at
every clock tried, where the old section went green in August. The first
draft of these checks was itself wrong in the same way and reproduced
the bug: it selected rows on "peak", which the NO_RECORD row does not
contain, so it dropped the row and then graded its absence. They select
on "quarter(s) banked" instead.
Full suite green, 15 files, at the real clock and at faked clocks in
2026-08, 2026-12, 2027-02 and 2027-03.
Left alone deliberately: only the UNREADABLE branch prefixes its row
with "capacity-tariff peak:". The NO_RECORD row carries neither that
phrase nor the word "peak". That asymmetry is what made the original
filter brittle and what broke the first draft above; it is product text
with other suites reading it, so it is reported rather than changed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU
admin
merged commit 358fbb0172 into release/1.02026-09-01 01:32:45 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes TEST-17.
release/1.0went red at 00:00 on 2026-09-01, on a commit nobody had touched.What broke
Controller.checks()read the capacity-tariff peak withself.peak.peak()- no argument - sotariff.py:410resolved the month asmonth_key(datetime.now(timezone.utc)).test_tariff.pysection 10 banks its quarter at the fixed fixtureB = 2026-08-30. From 1 September the status page was correctly asked for September, correctly answeredNO_RECORD, andexplain()returned"2026-09: no completed quarter recorded yet"- a string containing no"peak", which the section's filter at line 867 requires. It matched nothing, printedstatus row: (none), and four checks failed.Isolated by holding the commit and the image constant and moving only the clock, under
libfaketimein.gitea/ci's own image:all checks passed4 FAILEDIt fails identically at
f4914a1,04292c4~1and04292c4. The calendar, not a regression. Latent since TARIFF-01 merged on 2026-08-30; every PR that ever ran this suite ran it in August, so CI was legitimately green each time.What this changes
The product is right and the test was wrong, so the live page is untouched. Section 5 of this same file calls
NO_RECORD"a normal state on the 1st of the month", and a capacity tariff is billed monthly, so a page showing the current month is correct.checks()takeswhen: datetime | None = Noneand threads it intopeak()andwarning_frac(). This follows the existing convention rather than inventing one -PeakStore.peak(),PeakTracker.peak(),headroom_w()andwarning_frac()all already take exactly that parameter. The single production caller (status_payload(),main.py:1469) passes nothing and still means today.Why it cannot silently come back
Three new checks, none of which a clock can satisfy:
NO_RECORD, distinguishable from both an observed peak and an unreadable store;checks()with no argument must still mean today.Verified by mutation: a
checks()that dropswhenis red at every clock tried, where the old section went green in August.Worth knowing during review - the first draft of these checks reproduced the bug. It selected rows on
"peak", which theNO_RECORDrow does not contain, so it dropped the row and then graded its absence. They select on"quarter(s) banked"instead. That is thepickup.mdpattern "a reading that failed to observe anything gets treated as an observation", hit while fixing an instance of it.Verification
Full suite green, 15 files, in
.gitea/ci's image at the real clock and at faked clocks in 2026-08, 2026-12, 2027-02 and 2027-03 - which is also the evidence that no other suite carries a fixed-date fixture graded againstdatetime.now().One thing left alone deliberately
Only the
UNREADABLEbranch prefixes its row withcapacity-tariff peak:. TheNO_RECORDrow carries neither that phrase nor the wordpeak. That asymmetry is what made the original filter brittle and what broke the first draft above. It is product text with other suites reading it, so it is reported here rather than changed - say the word and it can be a follow-up card.