FlexMeasures / flexmeasures-client / 41698307534

95%

push

github

feat(client): wait for asynchronous ingestion of posted sensor data (#242)

* feat(client): wait for asynchronous ingestion of posted sensor data

Since FlexMeasures 1.1.0 a server with an ingestion worker available
answers a sensor-data post with 202 Accepted and the id of a background
job, and ingests the data after the request has returned. A caller that
posts a measurement and then reads it back, or asks for a schedule over
it, no longer sees what it just wrote: the post returns before the data
exists. That is what broke post-then-trigger in the S2 CEM and in the
simulation harness.

post_sensor_data now waits for that job by default, through wait_for_job,
so ingestion is polled, backed off and reported like every other job this
client waits for. A failed job raises JobFailedError, for the caller to
handle like any other failed post. A job still pending when the polling
timeout is reached is logged as an error and otherwise ignored: the data
may well land moments later, and a caller that has already waited that
long is better served by carrying on. Pass await_ingestion=False to
return as soon as the data is accepted.

Both the JSON and the file-upload path wait. The upload path does so
after its request block, rather than inside it: a job takes as long as
job_polling_timeout allows, which the request timeout around the upload
knows nothing about, and a wait that timed out there would have been
reported as a failed upload.

Carved out of #188.

Signed-off-by: F.N. Claessen <claessen@seita.nl>

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CcpawsJs74cSwFLXkz7ZwW

* fix(client): poll ingestion on its own profile, and name 0.33.0 as the version

Two corrections to the previous commit.

The server version was wrong. Asynchronous ingestion arrived in
FlexMeasures 0.33.0 (#2101), not 1.1.0, and the "job" field naming the
job was standardised later, in 1.0.0; 0.33.0 spelled it "job_id". Since
0.33.0... (continued)

48 of 52 new or added lines in 2 files covered. (92.31%)

995 of 1040 relevant lines covered (95.67%)

9.57 hits per line