FlexMeasures / flexmeasures / 39337744402

87%

push

github

Dispatch a schedule automation run again, queueing only the jobs it still owes (#2657)

* Name every job of a sequential schedule, rather than one name for the chain

A sequential schedule builds one job per device and one that wraps up, and forwarded a single `job_id` to every device job.
Nothing passed one, so nothing collided, but the moment a real id was passed each device job would overwrite the last.

Each job can now be named from a `job_id_prefix`: `<prefix>-device-<sensor id>` per device, and `<prefix>-wrap-up`.
Naming them after what they are for is what lets a second attempt at the same work recognise the jobs the first attempt queued,
which `create_scheduling_job` already acts on, as it leaves a job that exists where it is.

Working out which device each job computes for moved into `resolve_sequential_flex_model`.
A trigger may name the devices or leave them to the asset tree, so a caller that needs to know before the jobs exist
resolves them with the same function the scheduling service uses, rather than a second copy of the rule that can drift from it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0129WrXeJ5gia2pctFH93BqC
Signed-off-by: F.N. Claessen <claessen@seita.nl>

* Dispatch a schedule run again, queueing only the jobs it still owes

A schedule run was recorded, claimed and reported like any other, and then left where it failed:
its jobs took a fresh identity on every dispatch, so a second attempt could not tell an already queued schedule from a missing one,
and one clause in `get_dispatchable_automation_runs` kept such a run out of the retries.

A schedule run now says which jobs it intends to create before any of them exists in Redis, as a forecast run does,
with one intent per device and one for the job that wraps up, named after the run.
A second attempt reconciles those intents against Redis, leaves the jobs an earlier attempt queued alone,
and records only what it queue... (continued)

61 of 63 new or added lines in 2 files covered. (96.83%)

22188 of 25552 relevant lines covered (86.83%)

0.87 hits per line