feat: Add async FDv1 polling data source and feature requester

[jsonbailey]

Overview

PR 7 of the SDK-60 async epic: the async FDv1 polling data source and feature requester.

• async_polling.py — async FDv1 polling update processor. Polls the feature requester on an interval and pushes flag/segment data into the data source update sink, updating data source status (VALID / OFF) as appropriate.
• async_feature_requester.py — async FDv1 feature requester that fetches the full flag/segment payload over HTTP.
• test_async_polling.py — unit tests for the async polling update processor.

Stacking

This PR is stacked on #464 (base branch jb/sdk-2743/async-fdv1-streaming), which provides the shared datasource_common module these files import. Until #464 merges, this PR will also show #464's commits in its diff; a rebase after #464 merges will drop them, leaving only the three files here.

SDK-2825

---

Note

Medium Risk
New async data-source path affects client initialization and flag freshness; shutdown and HTTP error handling are security-adjacent but largely mirror existing sync logic with solid test coverage.

Overview
Adds the async FDv1 polling path for the Python SDK: periodic HTTP fetches of flags/segments, store initialization, and data-source status updates aligned with the sync polling processor.

AsyncFeatureRequesterImpl performs GETs to the FDv1 polling endpoint (optional payload filter query param), uses ETag / 304 caching, and only closes its HTTP transport when it created it.

AsyncPollingUpdateProcessor runs polls on AsyncRepeatingTask, writes via sink_or_store, sets ready when the store is initialized, and reports VALID, INTERRUPTED, or OFF (unrecoverable HTTP errors stop polling and unblock init wait). stop() waits for the repeating task to finish before closing the requester so the transport is not torn down mid-request.

AsyncRepeatingTask.wait_stopped() is new so callers can await background task unwind after stop().

Broad unit tests cover requester caching/errors, processor lifecycle, error recovery, sink status, and shutdown ordering.

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

[cursor]

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

^{❌ 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 5053397. Configure here.}

[cursor]

VALID status requires store initialized

Medium Severity

After a successful poll, async polling only emits DataSourceState.VALID when _store.initialized is true. Sync polling and async streaming update to VALID whenever the sink is present after a successful init. With a custom sink that does not mark the shared store initialized, status can stay non-VALID even though data was delivered.

 

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