Skip to content

Backward-compatibilty for forecasting/ingestion endpoints, QA workflow works with older clients - #2432

Open
nhoening wants to merge 19 commits into
mainfrom
feat/ci/qa-workflow-works-with-older-clients
Open

Backward-compatibilty for forecasting/ingestion endpoints, QA workflow works with older clients#2432
nhoening wants to merge 19 commits into
mainfrom
feat/ci/qa-workflow-works-with-older-clients

Conversation

@nhoening

@nhoening nhoening commented Aug 21, 2026

Copy link
Copy Markdown
Member

Description

We want to ensure backward-compatibility with older clients also for forecasting and data ingestion endoints which went to the 202 route. Their function would still work as normal, but fm-clients expect not just 2xx but specifically 200 and could break flows on the client side.

This PR dos that, and also improves the ability to signal legancy clients on assets or per QA run, and works on the QA/Release workflow to let us test legacy clients there.

  • add beackwards-compatible responses also for forecasting and ingestion (basically let them respond with 200 as before, ingestion would also stop being asynchronous), so older clients can get the responses they expect.
  • The legacy clients are adhered to with the asset attribute we introduced in fix: keep legacy 200/400 codes for older clients in schedule-related endpoints #2429. It is now renamed to indicate its wider scope and it can also be forced from config withut altering assets (only to be used in QA)
  • skip steps that older versions are not be able to run, like the ingestion tutorial or HEMS script - or enable them in QA/Release workflow if possible.
  • installation of packaged clients works differently than from branches
  • our recent work on backwards-compatibility should be baked into the FM assets / config we run
  • Added changelog item in documentation/changelog.rst

Here is an overview over the features we are now testing with legacy clients:

Client Ingestion Forecasting Scheduling Reporting
main ✅ API: file + JSON + read-back ✅ API via HEMS ✅ API: trigger + retrieve via HEMS ⚠️ CLI only
v0.9.4 ✅ API: file + JSON + read-back ✅ API via HEMS ✅ API: trigger + retrieve via HEMS ⚠️ CLI only
v0.9.0 ✅ API: file + JSON + read-back ✅ API via HEMS¹ ✅ API: trigger + retrieve via HEMS¹ ⚠️ CLI only
v0.8.0 ✅ API: file + JSON + read-back 🚫 No client API² 🧪 API: trigger + retrieve via HEMS¹ ⚠️ CLI only²
v0.7.0 ✅ API: JSON + read-back³ 🚫 No client API ❌ Not covered⁴ 🚫 No client API
  • ✅ Client API compatibility is tested.
  • 🧪 Coverage is implemented; successful workflow run still needs confirmation.
  • ⚠️ Exercised through the server CLI, not through a client API.
  • ❌ Potentially supported, but not covered by this workflow.
  • 🚫 The relevant client API did not exist.
  1. Uses legacy job-response compatibility.
  2. Client has no forecasting and/or reporting support yet. HEMS exercises the server CLI, but this does not test a client API.
  3. Uses legacy post_measurements(); file ingestion is unavailable.
  4. v0.7.0 has no HEMS example, so scheduling is not exercised.

The server CLI tutorials run in every workflow, but they are not counted as client backward-compatibility coverage.

How to test

Run the QA/release workflow with this branch, and try various client versions or branches

I ran these fm-clients:

Note: 0.7.0 has no HEMS script yet, as mentioned above.

Here is example output (from the Determine client QA capabilities):

=== Client QA plan ===
Requested client ref:              v0.8.0
Resolved client version:           0.8.0
Client source:                     PyPI release package
Data-ingestion tutorial:           true
HEMS example:                      true
Legacy job responses:              true
Legacy CLI wrapper:                true
v0.8.0 HEMS simulation shim:       true
Ingestion API support:             yes (file and JSON uploads)
Planned client ingestion:          API file and JSON uploads with read-back (tutorial)
Forecasting API support:           no
Planned client forecasting:        server CLI (HEMS; no client API)
Scheduling API support:            yes
Planned client scheduling:         API trigger and power/SoC retrieval (HEMS)
Reporting API support:             no (planned for FlexMeasures 1.1)
Planned client reporting:          server CLI (HEMS; no client API)
Server CLI tutorials 1-5:          run (not client-specific)
==============================

Signed-off-by: Nicolas Höning <nicolas@seita.nl>
Signed-off-by: Nicolas Höning <nicolas@seita.nl>
@read-the-docs-community

read-the-docs-community Bot commented Aug 21, 2026

Copy link
Copy Markdown

@nhoening nhoening self-assigned this Aug 21, 2026
@nhoening nhoening added this to the 1.1.0 milestone Aug 21, 2026
…rsion as ENV variable (for HEMS script to pick up) and in the new backward-compatibility config setting

Signed-off-by: Nicolas Höning <nicolas@seita.nl>
…e, which the ingestion tutorial uses; add a config setting to assume a client version which the HEMS script uses

Signed-off-by: Nicolas Höning <nicolas@seita.nl>
@Flix6x Flix6x changed the title Feat/ci: QA orkflow works with older clients Feat/ci: QA workflow works with older clients Aug 22, 2026
@nhoening nhoening changed the title Feat/ci: QA workflow works with older clients Backward-compatibilty for forecasting/ingestion endpoints, QA workflow works with older clients Aug 24, 2026
Context:
- Release QA skipped the ingestion tutorial for clients older than v0.9.4 even though earlier clients expose compatible ingestion methods.

Change:
- Install pinned releases from PyPI, adapt v0.7 post_measurements calls, skip only its unsupported file upload, and configure legacy responses before ingestion.
Context:
- Client v0.7.0 exposes post_measurements while later clients expose post_sensor_data.

Change:
- Verify current methods remain untouched and legacy clients receive a working alias.
Move the v0.8.0 HEMS fixtures to the next calendar year so uploaded prices remain visible at the simulation prior, and permit its play-mode loop to replace overlapping measurements.

Fail QA when older HEMS scripts catch scheduling errors or do not confirm that power and SoC schedules were retrieved.
Use standard find and grep commands to locate v0.8.0 HEMS fixture dates because ripgrep is not available on every Actions runner.
Signed-off-by: Nicolas Höning <nicolas@seita.nl>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant