Return meaningful results from the Train-Predict pipeline compute method

[BelhsanHmida]

Description

This pr aims to complete the return values of the TrainPredictPipeline.compute()

• Fixes the issue where TrainPredictPipeline.compute() always returned an empty list.
• Implementing return values:
  • When as_job = False, the pipeline now returns the computed forecast results. in format:

   {
       "data": <BeliefsDataFrame of forecasts>,
       "sensor": <Sensor object the forecasts are stored on>
   }

• When as_job = True, the pipeline returns a list of job IDs ["job-1": , "job-2": ].

[
    {"job-1": <job_id_1>},
    {"job-2": <job_id_2>},
    ...
]

CLI improvements:

• The flexmeasures add forecasts command now reports detailed success messages.
• When --as-job is set, it shows the number of forecast jobs created.
• When forecasts are computed directly, it shows the number of forecast beliefs and unique belief times created.
• If no forecasts or jobs are created, an error message is displayed instead of a generic success message.

How to test:

You can now run:
pytest flexmeasures/data/tests/test_train_predict_pipeline.py .

I added assertions to validate the return values of the pipelines, so the tests now cover both the as_job=False and as_job=True cases.

Related Items

closes #1811
...

---

Sign-off

• I agree to contribute to the project under Apache 2 License.
• To the best of my knowledge, the proposed patch is not based on code under GPL or other license that is incompatible with FlexMeasures

[read-the-docs-community]

Documentation build overview

📚 flexmeasures | 🛠️ Build #30593621 | 📁 Comparing d3638be against latest (235fe60)

🔍 Preview build

Show files changed (3 files in total): 📝 3 modified | ➕ 0 added | ➖ 0 deleted

File	Status
changelog.html	📝 modified
_autosummary/flexmeasures.data.models.forecasting.pipelines.predict.html	📝 modified
api/v3_0.html	📝 modified

[Copilot]

Pull request overview

This PR addresses issue #1811 by implementing meaningful return values for the TrainPredictPipeline.compute() method, which previously always returned an empty list. The changes introduce different return formats based on execution mode: forecast data with sensor information for synchronous execution (as_job=False), and job IDs for asynchronous execution (as_job=True).

Key changes:

• Added return_values instance variable to collect and return results from pipeline execution
• Modified run_cycle() to append forecast data and sensor information to return values
• Updated run() method to return job IDs when executing asynchronously
• Extended test assertions to validate the return value structure and content

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
flexmeasures/data/models/forecasting/pipelines/train_predict.py	Implements return value collection and handling for both synchronous and asynchronous execution modes
flexmeasures/data/models/forecasting/pipelines/predict.py	Returns the BeliefsDataFrame from the predict pipeline run
flexmeasures/data/models/forecasting/init.py	Conditionally skips event resolution validation when running as job
flexmeasures/data/models/data_sources.py	Conditionally skips sensor and source assignment when running as job
flexmeasures/data/tests/test_train_predict_pipeline.py	Adds comprehensive assertions to validate return values for both execution modes
flexmeasures/api/v3_0/sensors.py	Removes extra blank line (whitespace cleanup)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Flix6x]

Very nice. I believe I only have rather small suggestions.

[Flix6x]

One more note: if the response message in the forecasting CLI command incorporates this new feature, then this PR by itself also becomes a user-facing feature. And it's useful to consider that when writing the changelog entry (i.e. from a user perspective, how does this PR help them).

[BelhsanHmida]

One more note: if the response message in the forecasting CLI command incorporates this new feature, then this PR by itself also becomes a user-facing feature. And it's useful to consider that when writing the changelog entry (i.e. from a user perspective, how does this PR help them).

Thanks for the review, i applied the suggestions and added the changelog entry.

[Flix6x]

Thanks. Just the main changelog entry still.

[Flix6x]

Just one small formatting issue. Feel free to merge afterwards.