• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

FlexMeasures / flexmeasures / 21801020926
78%
main: 78%

Build:
Build:
LAST BUILD BRANCH: copilot/add-feature-request-470
DEFAULT BRANCH: main
Ran 08 Feb 2026 04:06PM UTC
Jobs 4
Files 173
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

08 Feb 2026 03:57PM UTC coverage: 77.782% (-0.01%) from 77.793%
21801020926

Pull #1953

github

web-flow
Fix parameter cleaning after Marshmallow kebab-case migration (#1961)

* Initial plan

* Add unified copilot environment setup file

Co-authored-by: Flix6x <30658763+Flix6x@users.noreply.github.com>

* docs: add changelog entries for bug fix and environment setup

Co-authored-by: Flix6x <30658763+Flix6x@users.noreply.github.com>

* fix: include last forecast event in get_forecast query

Context:
- Test test_trigger_and_fetch_forecasts was failing with 'P%P' instead of 'PT2H'
- Root cause: event_ends_before excluded the last event from the results
- When forecast period is short, this results in empty/incomplete data

Change:
- Add sensor.event_resolution to event_ends_before parameter
- Ensures all expected forecast events are included in the query
- Matches pattern already used correctly in the test code

Co-authored-by: Flix6x <30658763+Flix6x@users.noreply.github.com>

* revert: remove unnecessary event_ends_before adjustment in forecast API

Context:
- Previous fix added '+ sensor.event_resolution' to event_ends_before parameter
- Investigation revealed this was unnecessary - API behavior was correct
- event_ends_before is INCLUSIVE, so end_date correctly includes events ending at that time

Analysis:
- API correctly returns events with event_end = end_date
- For end_date=02:00 and 1h resolution, events 00:00-01:00 and 01:00-02:00 are correct
- Last event ends exactly at end_date (02:00), which is the expected behavior

Change:
- Reverted event_ends_before back to job.meta.get("end_date")
- Removed the '+ sensor.event_resolution' adjustment

See /tmp/DEBUGGING_FINDINGS.md for full investigation details

* fix(tests): test_forecasting_api now queries correct sensor

Context:
- Test was failing because it queried sensor_1 (solar-sensor-1)
- But API writes forecasts to sensor_0 (solar-sensor, the trigger sensor)
- This caused mismatch: API returned data from sensor_0, test expected data from sensor_1

Root Cause:
- Test used sensor_1 for manual pipel... (continued)
Pull Request #1953: Refactor/forecasting parameter datakeys

1621 of 2144 branches covered (75.61%)

Branch coverage included in aggregate %.

5 of 9 new or added lines in 3 files covered. (55.56%)

1 existing line in 1 file now uncovered.

11224 of 14370 relevant lines covered (78.11%)

6.24 hits per line

New Missed Lines in Diff

Lines Coverage ∆ File
1
94.64
-1.51% flexmeasures/data/schemas/utils.py
3
64.67
-0.04% flexmeasures/cli/data_add.py

Uncovered Existing Lines

Lines Coverage ∆ File
1
96.07
-0.44% flexmeasures/data/models/forecasting/pipelines/base.py
Jobs
ID Job ID Ran Files Coverage
1 21801020926.1 08 Feb 2026 04:06PM UTC 336
77.88
GitHub Action Run
2 21801020926.2 08 Feb 2026 04:06PM UTC 336
77.85
GitHub Action Run
3 21801020926.3 08 Feb 2026 04:06PM UTC 336
77.92
GitHub Action Run
4 21801020926.4 08 Feb 2026 04:06PM UTC 336
77.92
GitHub Action Run
Source Files on build 21801020926
  • Tree
  • List 173
  • Changed 6
  • Source Changed 5
  • Coverage Changed 5
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Repo
  • Github Actions Build #21801020926
  • Pull Request #1953
  • PR Base - feat/optional-training-start (#21800987418)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc