fix: Reuse an in-flight big segment status poll instead of always querying twice

[jsonbailey]

The status polling task queries the Big Segment store as soon as it starts, and get_status() also queries whenever no status is cached yet. A status request arriving while that first query was still in flight found nothing cached and sent a second query, so startup could cost two metadata queries instead of one.

A status request now waits for a poll that is already running rather than starting its own. The polling schedule is unchanged — the first poll still fires immediately, so nothing is delayed. get_user_membership now goes through get_status instead of repeating the cache check.

Never slower than before, and faster when the caller arrives after the poll started: with a 250 ms store round trip, a status request at t=100 ms gets its answer at 255 ms instead of 358 ms.

Testing

New regression tests on both the sync and async managers: with a slow get_metadata and a long poll interval, a startup status request must produce exactly one metadata query. Both fail assert 2 == 1 without the fix.

• pytest ldclient/testing (excluding integrations): 1667 passed
• make lint: clean, 229 source files
• Contract tests, zero failures: v3 sync 4756 ran, v3 async 4753 ran, v2 sync 4741 ran, v2 async 4738 ran

Tracked Internally: SDK-3212

---

Note

Overview
Fixes a startup race where the background Big Segment status poller and an uncached get_status() call could each issue a separate get_metadata query.

Sync and async BigSegmentStoreManager now coordinate polls with a lock: only one metadata query runs at a time, and callers with no cached status wait on an in-flight poll instead of starting another. Store querying is split into __query_store_status() (under the lock); listener notification moves to __notify_status() outside the lock to avoid deadlocks if a listener re-enters the manager. get_user_membership routes status through get_status() instead of duplicating the “poll if empty” path.

Regression tests assert exactly one metadata query when a status read overlaps the first slow poll at startup.

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

[joker23]

nit: I think there is still a chance for double notification if (somehow) poll does not obtain the lock before get_status(), but this is still a big improvement.

Suggestion would be to change the pr title to:

fix: Reuse an in-flight big segment status poll instead of always querying twice

[jsonbailey]

nit: I think there is still a chance for double notification if (somehow) poll does not obtain the lock before get_status(), but this is still a big improvement.

Suggestion would be to change the pr title to:

fix: Reuse an in-flight big segment status poll instead of always querying twice

Poll and Update status will always update status unconditionally, that is its job. Get status will only update status if one is not currently set, and it needs to ensure that the status it returns is also set in the status provider. If poll then also updates, the notifier will dedupe and ensure it isn't broadcast twice unless it has changed status between the two.