FlexMeasures / flexmeasures-client / 41603632562
95%

DEFAULT BRANCH: main
Ran
Jobs 10
Files 6
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
coverage: 95.622%. Remained the same
41603632562

push

github

web-flow 
fix(FRBC): stop answering stale requests, and stop sending instructions that ask for nothing (#237)

* refactor(s2): give control-type handlers a send_message()

Handlers reached into the CEM's _sending_queue directly, each with its own put() call and
its own comment explaining that this is how a message goes out.
That spread one decision - how a message leaves the CEM - over six call sites in three files.

ControlTypeHandler now offers send_message(), and the handlers call it.
Behaviour is unchanged: send_message() puts the message on the same queue.
It gives the queue a single owner, which is what lets later changes to sending
(awaiting a send rather than only queueing it) happen in one place.

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

* fix(FRBC): ignore a re-sent system description whose content is unchanged

The S2 specification gives a resource manager no way to say "my system description is
unchanged", so resource managers re-send it with every request payload, under a fresh
message id each time.
The base FRBC handler keyed on that message id, so every resend counted as news:
it was stored in the history and it spawned a schedule trigger, which in turn sent the
resource manager a full instruction batch.
In the FLEXED co-simulation that doubled the schedule triggers per timestep and was a large
part of the instruction storms observed there, on a serial S2 link where the acknowledgements
of those instructions then starved.

A description is now fingerprinted by its content, with the message id left out, and a
description whose fingerprint has not changed is acknowledged and otherwise ignored.
Acknowledging it still matters: without the reception status the resource manager would retry.
The TUNES handler has fingerprinted its descriptions this way all along; this brings the base
handler in line, and the TUNES handle... (continued)

961 of 1005 relevant lines covered (95.62%)

9.56 hits per line

Jobs
ID Job ID Ran Files Coverage
1 macos-latest - py3.11 - 41603632562.1 6
95.62
GitHub Action Run
2 macos-latest - py3.14 - 41603632562.2 6
95.62
GitHub Action Run
3 macos-latest - py3.13 - 41603632562.3 6
95.62
GitHub Action Run
4 ubuntu-latest - py3.11 - 41603632562.4 6
95.62
GitHub Action Run
5 ubuntu-latest - py3.12 - 41603632562.5 6
95.62
GitHub Action Run
6 macos-latest - py3.12 - 41603632562.6 6
95.62
GitHub Action Run
7 ubuntu-latest - py3.14 - 41603632562.7 6
95.62
GitHub Action Run
8 macos-latest - py3.10 - 41603632562.8 6
95.62
GitHub Action Run
9 ubuntu-latest - py3.13 - 41603632562.9 6
95.62
GitHub Action Run
10 ubuntu-latest - py3.10 - 41603632562.10 6
95.62
GitHub Action Run
Source Files on build 41603632562