feat: Add async FDv1 streaming and data source status tracking

[jsonbailey]

Overview

Adds the async FDv1 streaming data source and its companion async data source status tracking, plus a new shared sans-I/O datasource_common module. This is one slice of the async Python SDK work.

What's included

• Async FDv1 streaming data source (ldclient/impl/datasource/async_streaming.py) — driven by ld_eventsource's AsyncSSEClient and owning its own aiohttp session via make_client_session. It consumes SSE put/patch/delete events and pushes the resulting data into the async data source update sink.

• Async data source status tracking (ldclient/impl/datasource/async_status.py — AsyncDataSourceUpdateSinkImpl and friends). The streaming source pushes data and status transitions into this update sink, so the two are runtime-coupled and land together in this slice.

• New shared sans-I/O datasource_common module (ldclient/impl/datasource/datasource_common.py) — STREAM_ALL_PATH, sink_or_store, and parse_path. Both the sync data sources and the new async streaming source use it.

• Behavior-preserving extraction of the sync data sources. streaming.py and polling.py are routed through datasource_common: the inline _sink_or_store/_parse_path/STREAM_ALL_PATH/ParsedPath definitions are removed in favor of importing the shared helpers, with call sites switched accordingly. No behavior change. The shared module is also needed by the upcoming async polling slice.

• Unified status provider (sync/async). The async status provider was unified with the sync one: the redundant AsyncDataSourceStatusProviderImpl (which had no async-specific behavior — byte-identical to the sync provider apart from its sink type) is removed, and the async data system now reuses the sync DataSourceStatusProviderImpl. To let both sinks satisfy it structurally, the sync provider's update_sink parameter was widened to a small status-only Protocol (_DataSourceStatusSource). This is the same interface-segregation pattern as the PR 1b config read-protocols and mirrors the already-unified big-segment status provider. This adds a small behavior-preserving change to sync status.py.

Notes

• The async public class carries the experimental .. caution:: block.
• No CHANGELOG entries or version bumps (handled at release time).

Tracked internally: SDK-2743

---

Note

Medium Risk
Touches live flag-ingestion paths (streaming, store versioning, change listeners) in new experimental async code; sync changes are mostly shared-helper extraction with interface widening for status providers.

Overview
Introduces async FDv1 streaming via AsyncStreamingUpdateProcessor, which consumes SSE put/patch/delete events, reports data-source status, and writes through the configured update sink (with optional owned aiohttp session lifecycle).

Adds AsyncDataSourceUpdateSinkImpl for async store updates, dependency tracking, status broadcasts, and flag-change notifications—only when the async store actually applies an upsert/delete (stale versions are ignored).

AsyncFeatureStore.delete now returns a bool (mirroring upsert) so the async sink can skip listener noise on rejected deletes; the in-memory async store implements this.

Extracts datasource_common (STREAM_ALL_PATH, sink_or_store, parse_path) and wires sync streaming and polling through it without intended behavior changes.

Unifies status reporting by typing DataSourceStatusProviderImpl against a small _DataSourceStatusSource protocol so sync and async sinks share one provider.

Includes broad async unit tests for the sink and streaming processor (mock SSE, errors, session ownership).

^{Reviewed by Cursor Bugbot for commit 52de7f6. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Store error kind overwritten

Medium Severity

When the update sink reports STORE_ERROR and re-raises, the streaming processor's broad Exception handler calls update_status again with UNKNOWN. Because a new error is supplied, status is broadcast again and the more specific STORE_ERROR kind is replaced.

Additional Locations (1)

• ldclient/impl/datasource/async_status.py#L41-L47

 

^{Reviewed by Cursor Bugbot for commit 73977fd. Configure here.}

[jsonbailey]

This mirrors the sync data source status sink rather than being an async-only issue: sync's __monitor_store_update also re-raises after setting STORE_ERROR, and the sync streaming run() has the same broad except Exception that then calls update_status(INTERRUPTED, UNKNOWN) and overwrites the more specific kind. Keeping async in parity with sync here; if the overwrite is worth correcting it should be fixed in both sync and async as a separate change. Tracked as a follow-up.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 89de1c5. Configure here.}

[cursor]

Wrong update processor base class

Medium Severity

AsyncStreamingUpdateProcessor subclasses sync UpdateProcessor instead of AsyncUpdateProcessor. That mismatches the async config factory contract and the async stop lifecycle (UpdateProcessor.stop is synchronous), so type checks and any isinstance/interface consumers treat this processor as the sync variant.

 

^{Reviewed by Cursor Bugbot for commit 89de1c5. Configure here.}