chore: Fix flaky FlagSynchronizerSpec tests (SDK-2042)

[devin-ai-integration]

BEGIN_COMMIT_OVERRIDE
chore: Fix flaky FlagSynchronizerSpec tests
END_COMMIT_OVERRIDE

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

• SDK-2042
• Observed on PR #482 CI runs

Describe the solution you've provided

Fixes two flaky tests in FlagSynchronizerSpec.swift, each in a separate commit:

1. change_isOnline__online_to_offline__stops_polling — Moved isOnline = false inside the onSyncComplete callback, before signaling the semaphore. This prevents a second timer tick from firing between the callback and the assertion, which caused getFeatureFlagsCallCount to be 2 instead of 1 on slow CI runners. This is the same pattern already applied to pollingTimerFiresSpec in PR chore: Parallelize builds to cut down CI wall clock time #481.

2. streaming_events__event_reported_while_polling__reports_an_event_error — Added an explicit 5-second timeout to the first waitUntil block. The default 1-second timeout was insufficient for the multi-hop async callback chain (main RunLoop → syncQueue → getFeatureFlags → reportSyncComplete → DispatchQueue.main.async) on loaded CI runners. The 5-second timeout is consistent with other async tests in the codebase (e.g., DarklyServiceSpec, EventReporterSpec).

Both changes are test-code-only; no application code is modified.

Describe alternatives you've considered

For fix 2, an alternative was converting to the semaphore + RunLoop pump pattern used elsewhere in FlagSynchronizerSpec. However, waitUntil(timeout:) is the dominant async pattern in the test suite (16 call sites across 4 files), so an explicit timeout is more consistent and a smaller change.

Additional context

For reviewers: The second waitUntil in the event_reported_while_polling test (the one waiting on testStreamOnMessage) still uses the default 1-second timeout. That chain is simpler (no timer hop — just a direct DispatchQueue.main.async dispatch), so 1 second should remain sufficient. Worth confirming this matches your understanding.

Link to Devin session: https://app.devin.ai/sessions/1db84bb989a24b319cbc345be77efaac

---

Note

Low Risk
Test-only changes that adjust async coordination and timeouts; low risk aside from potentially masking real timing regressions if timeouts are too generous.

Overview
Fixes flakiness in FlagSynchronizerSpec polling-related tests by stopping polling inside the onSyncComplete callback (before unblocking assertions) to avoid extra timer ticks racing the expectations.

Also increases the first waitUntil timeout to 5 seconds for the “event reported while polling” case so the multi-hop async setup reliably completes on slower CI runners.

^{Written by Cursor Bugbot for commit 2be732e. This will update automatically on new commits. Configure here.}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring