Stop the asset page's KPIs counting a day the chart does not show

[Flix6x]

Description

KPIs on the asset page cover one day more than the chart beside them.

• ui/graphs: pass the chart's end date to the KPI endpoint unchanged
• Added changelog item in documentation/changelog.rst

getAssetKPIs advanced its end date by a day, to "make the end date inclusive". But both callers already hand it the chart's exclusive end — the picker applies +1 day before calling, and event_ends_before is exclusive on the initial page load. The endpoint ends its own window before end as well: _get_sensor_stats filters TimedBelief.event_start < end_dt.

Advancing the date also mutated it in place, and that Date object is the one held by storeEndDate and previousResult.end, so the chart's own end date moved a day forward on every selection. Not advancing it at all fixes both, which is why this is a one-line change.

Where the extra day came from

The advance was not arbitrary, and it was once correct. Until #1909 this function took no arguments and read the picker directly:

var endDate = picker.getEndDate();
endDate.setDate(endDate.getDate() + 1);

picker.getEndDate() is the last day selected — 7 January for a 1–7 January selection — so advancing it produced the exclusive end the endpoint wants.

#1909 ("fix: pass start and end dates to getAssetKPIs() on graphs page", closing #1908, shipped in v0.30.3, January 2026) gave the function startDate/endDate parameters, because reading the picker broke page load. Both callers pass the chart's already-exclusive end: the picker handler applies +1 day before calling, and event_ends_before is exclusive on the initial load. The advance inside was carried over unchanged, and from that point added a day too many.

So this is a regression from #1909 rather than the undoing of a deliberate decision. Its own changelog entry stays as it is: #1909 shipped in v0.30.3, so this is a fix to released behaviour, not to an unreleased regression. I have left a comment where the advance used to be, so it does not get put back.

Warning

This changes reported KPI values. They were too high (or too wide, for min/max) by one day's worth of data. Anything tracking them will step down when this lands. The old numbers were wrong, but the change is visible.

Look & Feel

On a seeded asset carrying one unit of energy per day, asking for a three-day window:

end sent	KPI total
T0+3d (what the chart shows)	3.0
T0+4d (what the UI sent)	4.0

How to test

test_kpi_window_end_is_exclusive in flexmeasures/api/v3_0/tests/test_assets_api.py asserts that a three-day window over one daily value per day totals three, not four.

To be explicit about what that test does and does not cover: it pins the endpoint's window semantics, which the page depends on. It does not exercise the JavaScript change, and would pass without it — there is no JavaScript test runner in this repo. The front-end half was verified by hand, by reading the end parameter off the request the page issues.

Manually: open an asset page with KPIs configured, select a range, and compare a KPI against the chart beside it. Before this change a sum covers one day more than the chart draws.

Notes

Split out of #2433 at the maintainer's request, because it changes user-visible numbers while that PR is a performance change. #2433 also carries this fix, so the two converge: graphs.html merges cleanly in either order (verified by a trial merge). The changelog entry lives here, and has been removed from #2433 to avoid a duplicate line.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Note

This error may be related to your runner configuration. You can now configure runners for Copilot code review separately from Copilot cloud agent by creating a copilot-code-review.yml file with your setup steps. Read the docs for details.

[read-the-docs-community]

Documentation build overview

📚 flexmeasures | 🛠️ Build #34196825 | 📁 Comparing 85116ec against latest (3272084)

  🔍 Preview build  

10 files changed · ± 10 modified

± Modified

• changelog.html
• configuration.html
• genindex.html
• _autosummary/flexmeasures.api.common.responses.html
• _autosummary/flexmeasures.api.common.utils.api_utils.html
• _autosummary/flexmeasures.data.html
• _autosummary/flexmeasures.data.models.planning.storage.html
• _autosummary/flexmeasures.data.utils.html
• api/v3_0.html
• concepts/flexibility-configuration.html

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Note

This error may be related to your runner configuration. You can now configure runners for Copilot code review separately from Copilot cloud agent by creating a copilot-code-review.yml file with your setup steps. Read the docs for details.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Note

This error may be related to your runner configuration. You can now configure runners for Copilot code review separately from Copilot cloud agent by creating a copilot-code-review.yml file with your setup steps. Read the docs for details.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Note

This error may be related to your runner configuration. You can now configure runners for Copilot code review separately from Copilot cloud agent by creating a copilot-code-review.yml file with your setup steps. Read the docs for details.

[Flix6x]

Copilot review requested three times (17:22, 17:31, 17:35 UTC); each attempt came back with "Copilot encountered an error and was unable to review this pull request", referring to runner configuration. Requests on #2433 and #2435 in the same window succeeded, including ones touching this same file, so it looks specific to this PR or transient on their side rather than something in the diff.

Not retrying further to avoid noise. @Flix6x, worth a re-request from your side later, or a human review — the change is one line plus a test.

CI is green: 13/13 checks pass.

[Flix6x]

Added the toIsoStringWithOffset fix here too, per @Flix6x. It is a second, independent error in the same KPI window: this PR fixes an end date a day too late, that one fixes both ends being shifted by the viewer's UTC offset. West of UTC the shift lands on a different day for daily-resolution sensors, so the two compound.

The file is byte-identical to the version in #2435, where the JavaScript tests that found it live, so the branches merge in either order. The changelog entry for it stays in #2435, to avoid the line appearing twice.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Note

This error may be related to your runner configuration. You can now configure runners for Copilot code review separately from Copilot cloud agent by creating a copilot-code-review.yml file with your setup steps. Read the docs for details.

[Flix6x]

Update on the Copilot review: five attempts now, across three different commits, spanning about two hours — every one returned "Copilot encountered an error and was unable to review this pull request".

attempt	commit	result
16:23	e07e5ad8c	errored
17:23	4a242f557	errored
17:30	4a242f557	errored
17:35	4a242f557	errored
18:11	a48553b40	errored

Requests on #2433 and #2435 succeeded during the same windows, including ones touching this same file, so it is specific to this PR rather than a general outage or anything in the diff. I have stopped retrying.

This PR therefore has had no automated review at all, which is worth knowing given it is the one that changes reported KPI values. @Flix6x, a re-request from your account may fare better; otherwise it is worth a human read. The change is two one-line fixes plus a test.

CI is green: 13/13.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Note

This error may be related to your runner configuration. You can now configure runners for Copilot code review separately from Copilot cloud agent by creating a copilot-code-review.yml file with your setup steps. Read the docs for details.

[Flix6x]

Copilot could not review this one (five attempts, all erroring), so I ran three adversarial reviewers locally instead — one on the KPI-window claim, one on timezone correctness, one on test quality. Between them they found five things worth acting on. All are now addressed; the core claim survived.

What survived. The claim that both callers pass an exclusive end was checked by rendering the page for FLEXMEASURES_MODE both normal and play and parsing the emitted script: exactly one definition and two call sites in both, both passing an exclusive end. The #1909 history in the comment checks out against git show aa7f8c90e. And toIsoStringWithOffset survived 1,151,931 assertions across 14 timezones — every DST transition instant in 2019–2027 ±3h, sub-hour offsets (+05:45, +13:45), the repeated hour, and padding edges — with zero failures, and its output verified to parse to the right instant through the real AwareDateTimeField.

What changed.

1. The test proved nothing about the fix. Both fixes are JavaScript; the test drove the endpoint, which this branch does not touch. It passed on main and would pass with both fixes reverted. The repo asks that a new test be shown to fail first. There is now a rendered-page assertion that getAssetKPIs passes its window on untouched — reintroducing endDate.setDate(endDate.getDate() + 1) turns it red, which is exactly how the regression fix: pass start and end dates to getAssetKPIs() on graphs page #1909 introduced would have been caught. No new dependency; it reads the page the Flask test client renders.

2. The endpoint test could not see a shifted window. Every belief was worth 1.0, so it counted days rather than identifying them — any three-day window passed. Days now carry distinct values, so the right window totals 6.0 and an hour-shifted one totals 9.0, with an explicit total != shifted assertion so that discrimination cannot rot. Proved red by inverting the endpoint's event_start < end_dt to <=.

3. Three comments described behaviour that no longer exists. Two still gave "getAssetKPIs bumps storeEndDate by +1 day" as the reason fastChartWindow is snapshotted as epoch numbers — load-bearing, since a maintainer trusting it could drop the snapshot or restore the advance. One is on this branch, the other was on Load only the newly selected days when a chart's time range changes #2433, fixed there in 9f3ecd2 with matching wording so the two stay identical.

4. The comment overstated the agreement. It said the endpoint ends its window "exactly as the chart does". The predicates differ — the chart keeps events whose end falls on the window's end, the endpoint keeps events whose start falls before it — and they agree only for the daily, midnight-aligned sensors this endpoint documents. For an instantaneous sensor the KPI is now one event short of the chart. Reworded to say so.

5. Fixture borrowing. The new rendering test took an asset from a shared fixture that earlier tests in the same module delete; it built its own. Both files pass under random ordering.

One thing I am leaving, and flagging instead. Removing the advance also stops storeEndDate being corrupted for the rest of the page session, which means the chart's own reloads after an upload or delete, the chart-type re-embed, and the replay bounds were all a day too wide on KPI-enabled asset pages. That is real and now fixed, but its changelog line lives on #2433 ("the chart's selected end date was pushed a day forward on every date selection"), so if this PR merges alone that symptom ships undocumented. It also makes the previousResult.end.getTime() === endDate.getTime() short-circuit in fetchGraphDataAndKPIs reachable on KPI pages for the first time, since that comparison could never succeed while the date was being mutated.

99 tests pass across the two touched modules, under random ordering.