feat: Add async FDv2 data system

[jsonbailey]

Overview

Part of the async Python SDK work (epic SDK-60). Adds the async FDv2 data system (coordinator) and wires it into the async client. Targets main (its predecessor, #485 async FDv2 data sources, has merged).

This is experimental and should not be considered production-ready.

What this PR adds

• impl/datasystem/async_fdv2.py — AsyncFDv2, the async data system that coordinates the async initializers and synchronizers, mirrors the sync FDv2 fallback/recovery behavior, and exposes the async data source status and flag tracking. Includes AsyncFeatureStoreClientWrapper for persistent-store availability polling.
• async_client.py wiring: _make_data_system builds AsyncFDv2; _wire_data_source_sessions shares the client's aiohttp session into the async data source builders so they reuse the connection pool.

Async readiness gate (awaitable end-to-end)

Readiness and availability are now awaitable so a persistent store populated by another process (warm start / daemon) is recognized:

• AsyncDataSystem.data_availability and AsyncLDClient.is_initialized() are coroutines; the eval path awaits data_availability() directly.
• AsyncFeatureStore gains an abstract async is_initialized() (with $inited caching + monotonic latch in AsyncCachingStoreWrapper, surfaced via AsyncStore.is_ready()). The getattr duck-type is dropped, so a custom store that omits it fails at construction rather than silently serving defaults.
• The gate catches a persistent-store error and degrades to DEFAULTS rather than raising, so variation() never throws on a store outage. (Sync counterpart: fix: Do not propagate persistent-store errors from the sync FDv2 warm-start check #506.)

Wrapper hardening

• is_monitoring_enabled() delegates to the store's own opt-in (matching sync), so a store that cannot report availability is not polled and left stuck unavailable.
• close() is idempotent, bounds the availability-poller stop with a timeout, and logs errors from the inner store close.
• AsyncStore.close() logs and swallows close errors instead of returning them.

Shared refactor

• impl/datasystem/fdv2_common.py gains module-level fallback_condition / recovery_condition, shared by the sync and async data systems.

Testing

• LD_SKIP_DATABASE_TESTS=1 uv run pytest ldclient/testing/impl/datasystem/ and ldclient/testing/test_async_client.py — green.
• make lint (mypy, isort, pycodestyle) — clean.

Tracked internally: SDK-2870

---

Note

Overview
Adds async Flag Delivery v2 support by introducing AsyncFDv2, wiring it into AsyncLDClient when datasystem_config is set (replacing the previous NotImplementedError), and sharing the client's aiohttp session with async polling/streaming data source builders via _wire_data_source_sessions.

Readiness and availability are now async so persistent stores populated by another process can be detected: AsyncLDClient.is_initialized(), AsyncDataSystem.data_availability(), and a new AsyncFeatureStore.is_initialized() (with caching/latching in AsyncCachingStoreWrapper and AsyncStore.is_ready()). Contract-test harnesses await these checks accordingly.

Sync FDv2 is refactored to share wiring through _FDv2Base and module-level fallback_condition / recovery_condition in fdv2_common.py. AsyncFDv2 mirrors initializer/synchronizer coordination, FDv1 fallback, persistent-store outage recovery, and adds AsyncFeatureStoreClientWrapper for availability polling.

AsyncStore.close() logs and swallows close errors instead of returning them. Large new test suites cover AsyncFDv2, async persistence, and readiness gating.

^{Reviewed by Cursor Bugbot for commit 111bb37. 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 2 potential issues.

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

[keelerm84]

We are changing the spec and the logic around this. I think it's fine to leave for now, but just making sure it's on your radar.

[joker23]

Are we checking for the store is_available elsewhere now?

[jsonbailey]

Yes. The recovery poller still calls is_available, in _check_availability. This method now decides only whether to monitor. It uses the store's own opt-in (is_monitoring_enabled), which is true when the core provides is_available.

[joker23]

I think this could get us into another situation where we never close since the boolean is set before any of the actual closing happens... this might be fine if we think that calling the stop/close functions are our best effort.

[jsonbailey]

Correct, and this is best-effort by design. We set the flag first so a second close() call does nothing. Both teardown steps have their own guards, so neither one raises. Only task cancellation can stop the close early, which means an abnormal shutdown. If you want a retry after a failed close, we would need a lock so callers wait for the first close — more than a shutdown path needs, but I can add it if you prefer.

[joker23]

not sure if this is a problem, but does python do truthy so when is_initialized() returns a future then if client.is_initialized() will always test true?

[jsonbailey]

is_initialized() is now a coroutine, so if client.is_initialized() is always true unless you await it. This applies to every async method here, such as variation and all_flags_state. The fix is to await the call. The docstring now states that it is a coroutine, and all internal calls await it.