[adapters] Add the set of running syncs to CheckpointSyncStatus. - #6930

Ran locally: cargo check --locked -p feldera-types and -p dbsp_adapters (both clean), uv run --locked pytest tests/unit in python/ (89 passed), and drove Pipeline.sync_checkpoint_status directly against synthetic responses — the new-server, old-server, UUID-object and re-sync-of-a-previous-success cases all classify correctly, and the last one is a genuine improvement over the old uuid > success heuristic. The CheckpointSyncGuard shape is right: RAII release means an aborted or panicking sync task still frees its slot, and #[serde(default)] keeps a new manager readable against an old pipeline. Three things to fix, detailed inline:

Uncovered cases worth adding, in rough priority order: (a) saw_running is only printed, never asserted, so no test deterministically proves running is ever populated — a server that never implemented the field passes both tests whenever the poll misses the window; (b) the de-duplication path (try_new returning None) has no test at all, even though it is the only new behavioural change on the REST surface; (c) Pipeline.sync_checkpoint_status is pure response-parsing and belongs in python/tests/unit with a mocked client — the running-present, running-absent and stale-success branches are all cheap to pin there and would not need a live instance; (d) nothing exercises two distinct UUIDs in running concurrently, which is the case the BTreeSet exists for. python/tests/platform needs a live Feldera instance, so I read those rather than running them. Commit message is good — imperative subject, body explains the why.

Reviewed against feldera-pr-checks. Design is sound — running is inserted under the same lock that later moves the UUID to success/failure, and it happens before the 202 is written, so a client polling after the request can't see the UUID vanish. #[serde(default)] plus the manager forwarding the pipeline's body verbatim (forward_http_request_to_pipeline_by_name) means the "field absent = old pipeline" contract the SDK relies on really does hold end to end. Docs, openapi regeneration and the commit message are all in good shape.

What I ran

Gates

• Flaky tests — fails. test_sync_status_running_after_failure's 5-attempt saw_running loop is a race against a local MinIO 403, and it self.fail()s when it loses. Details inline.
• Unit tests — weak. The Python classifier is well covered, but the Rust guard (coalescing, Drop) has no test at all, and the happy-path integration test discards saw_running, so removing the running bookkeeping entirely would leave both integration tests green.

Uncovered cases I found

1. success and failure both naming the same UUID — the SDK reports Success for a re-sync that failed (verified locally); inline suggestion clears the stale slot server-side.
2. Multihost / coordination_checkpoint_push coalescing — both new tests are @single_host_only.
3. Guard dropped without completed() (task cancelled at shutdown): UUID leaves running with no terminal record, so sync_checkpoint(wait=True) polls to timeout.
4. periodic and running interacting — docs say periodic syncs never appear in running; nothing asserts it.
5. running non-empty for a different UUID is covered in the unit table, but not running: [OTHER] combined with an old-pipeline response shape.

Ran cargo check --locked -p feldera-types -p dbsp_adapters (clean), uv run --locked pytest tests/unit in python/ (104 passed, including the 15 new ones), and pre-commit run --files <changed> (all hooks pass, Update OpenAPI confirms the spec is in sync). Read python/tests/platform/test_checkpoint_sync.py rather than running it. The design is nice — registering in running before answering the 202 closes the observation window, and the guard makes the release-on-drop path hard to get wrong. Two things to resolve before merge, both inline: the success = None on a later failure of the same UUID is a user-visible regression (last_successful_checkpoint_sync() starts raising "no checkpoints have been synced yet" for a checkpoint that is sitting in the bucket), and BLACKHOLE_ENDPOINT bakes in a runner-network assumption that turns into a red test elsewhere. One gate to call out: the changed server behaviour — coalescing, and clearing the opposite outcome — has no Rust unit test, and its only coverage is @enterprise_only platform tests that are skipped in the OSS run; the new unit tests cover the SDK classifier, not sync_checkpoint().

Cases the tests do not reach:

Two smaller notes, no action needed if intentional: (1) OpenAPI gives running "default": [], so generated clients coerce absent to empty and cannot make the absent-vs-empty distinction the docs tell readers to rely on — only the hand-written Python path preserves it; worth a sentence in the docs saying the distinction is SDK-level. (2) A wedged sync now blocks every future sync request for that checkpoint for the life of the process, with no timeout and no cancel — your own test_sync_status_in_flight has to stop(force=True) to get out. Also, the commit subject is fine for the size, but a short body explaining why coalescing and outcome-clearing were chosen would be worth having in the history, since neither is evident from the diff.

I think I've fixed all the substantive feedback here.

you might need to rebase on main and regenerate openapi.json for pre merge queue tasks to pass