-
Notifications
You must be signed in to change notification settings - Fork 55
fix: keep legacy 200/400 codes for older clients in schedule-related endpoints #2429
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
nhoening
merged 6 commits into
main
from
fix/backward-compatibility-switch-for-schedule-accepted-status
Aug 20, 2026
Merged
Changes from 2 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
d0cc294
fix: keep legacy 200/400 codes for older clients in schedule-related …
nhoening d19f593
docs: fix broken changelog links
BelhsanHmida 45427cb
combine into one setting, do not fail if settings format is not a dict
nhoening 262b29d
Merge branch 'fix/backward-compatibility-switch-for-schedule-accepted…
nhoening d357a3b
docs: note the 202 response when polling an unfinished schedule
BelhsanHmida 4791285
fix(api): do not let an empty client-version attribute shadow its parent
BelhsanHmida File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest introducing one less configuration setting, by combining the two:
FLEXMEASURES_LEGACY_SCHEDULEACCEPTED_STATUS: {"v2g-liberty-version": "0.9.1"}This also makes it possible to have more than one entry for matching.
Better would be to match the version with the actual v2g-liberty version, and only use the fm-client version if that's the actual attribute.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, having only one setting is easier, and mostly allowing more than one attribute to be used helps to support more partners with client systems.
I don't understand what you mean actually. We don't know the "actual" v2g-liberty version aside from what these users put in the asset attributes. There is no fm-client version that we know of - I will prioritize FlexMeasures/flexmeasures-client#212 so that we start collecting it, but that is not relevant to FM v1.0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought @ArdJonker was storing both the v2g-liberty version and the flexmeasures-client version as asset attributes on the main connection asset (the one that a schedule is triggered on).
And I thought it would make sense to not mix up versions in our new config setting. So, for instance, if they store:
we'd not want a setting like:
because the value and key then represent different dependencies.
Rather, I was thinking of:
to apply legacy status on all assets with their v2g-liberty-version attribute set to lower than 0.8.0, or
to apply legacy status on all assets with their flexmeasures-client attribute set to lower than v0.9.1, or
to apply legacy status on all assets with their v2g-liberty-version attribute set to lower than 0.8.0 or their flexmeasures-client attribute set to lower than v0.9.1.
Footnotes:
flexmeasures-client: <0.9.1.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, from what I see he is storing:
The former impicitly would tell us which fm-client is used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked about the "v" robustness, and we use packaging.version.Version, which handles that correctly.