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

FlexMeasures / flexmeasures / 36182029517
86%

Build:
DEFAULT BRANCH: main
Ran 25 Sep 2026 08:03PM UTC
Jobs 1
Files 186
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

25 Sep 2026 07:49PM UTC coverage: 86.103% (+0.2%) from 85.942%
36182029517

push

github

web-flow
Feat/2393 durable automation runs (#2457)

* feat(data/models): add durable automation run records

An automation occurrence currently leaves no trace of its own: the only durable
marker is the automation's scheduling cursor, which says an occurrence was
attempted, not what happened to it.

Record each occurrence a runner picks up as an AutomationRun, with the attempts
made on it (AutomationRunAttempt) and the jobs it intends to create
(AutomationRunJob). Dispatch progress and worker execution outcome are tracked
separately, because 'queued everything' and 'the jobs succeeded' are different
questions an operator needs answered.

The database enforces one run per automation, occurrence and schedule revision,
and one job intent per run and logical job key. The new schedule revision on
Automation keeps runs of an edited or reactivated schedule apart from the runs
of the schedule it replaced, even at the same scheduled UTC time.

All run timestamps are validated to be timezone-aware and stored as UTC.

Signed-off-by: Mohamed Belhsan Hmida <mohamedbelhsanhmida@gmail.com>

* feat(data/services): claim automation occurrences durably and resume partial dispatch

The runner used to advance and commit the scheduling cursor before queueing
anything, guarded only by a Redis key with a two-minute TTL. A failure before
the first enqueue therefore lost the occurrence for good, while retrying a
partial enqueue could have duplicated work.

Claim each due occurrence into an AutomationRun instead, write down the plan for
the run before the first enqueue, and give every intended job a logical key and,
from it, a deterministic RQ job ID. A retry replays that stored plan: jobs whose
IDs are already in Redis are recognised and left alone, and only the missing ones
are queued. Because the plan holds the parameters and timings the occurrence was
planned with, a retry hours later still dispatches the occurrence as originally
intended, even if the automation has been edited sin... (continued)

462 of 487 new or added lines in 8 files covered. (94.87%)

1 existing line in 1 file now uncovered.

20055 of 23292 relevant lines covered (86.1%)

0.86 hits per line

Uncovered Changes

Lines Coverage ∆ File
16
94.01
0.09% flexmeasures/data/services/automations.py
5
95.51
-1.46% flexmeasures/data/models/automations.py
2
46.84
-0.75% flexmeasures/cli/jobs.py
2
88.0
-6.74% flexmeasures/data/services/forecasting.py

Coverage Regressions

Lines Coverage ∆ File
1
94.01
0.09% flexmeasures/data/services/automations.py
Jobs
ID Job ID Ran Files Coverage
1 36182029517.1 25 Sep 2026 08:03PM UTC 186
86.1
GitHub Action Run
Source Files on build 36182029517
  • Tree
  • List 186
  • Changed 8
  • Source Changed 8
  • Coverage Changed 8
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #36182029517
  • 059cdbdc on github
  • Prev Build on main (#36160291509)
  • Next Build on main (#36191867000)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc