Conversation
APITests and FakeConsoleTests read `self.config` inside fetch and activate completion handlers, but APITestBase.tearDown() sets `config` to nil. When a test times out, its activate completion can still run later, unwrap nil, and crash the test process. On the visionOS CI jobs this turned three expectation timeouts into a crash and a test-runner restart. Capture a local strong reference to `config` at the start of each test and use it in the handlers, so a late handler runs against a valid instance instead of crashing. Document the pattern on APITestBase.config.
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. |
This branch has not been deployed
1 participant
Problem
The RemoteConfigFakeConsole visionOS jobs (
spm_2) are flaky:The same sequence happens each time:
APITeststestFetchThenActivate,testFetchWithExpirationThenActivateandtestUnchangedActivateWillFlagexceed their 10 s expectation timeout.activatecompletions arrive later, aftertearDown()has setconfig = nil. They then crash the test process withAPITests.swift:46: Fatal error: Unexpectedly found nil while implicitly unwrapping an Optional value(and the same at:78).Change
APITestsandFakeConsoleTestsnow capture a local strong reference toconfigat the start of each test and use it in the completion handlers. A late handler runs against a valid instance instead of crashing. The pattern is documented onAPITestBase.config.Testing
I reproduced the CI crash locally on a visionOS 26.5 simulator. I saturated the host CPU with 24 busy loops on a 16-core Mac and temporarily cut the
APITeststimeout to 0.3 s.APITests.swift:46,:60and:78crash with the CI fatal error; the runner restarts twiceWhy the completions are late
This PR stops the crash. It does not stop the timeouts.
activate's completion waits for-[FIRExperimentController updateExperimentsWithServiceOrigin:...], which dispatches todispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0). When the CPU is saturated, background-QoS work is starved. CI runners hosting the visionOS simulator are in exactly that state.Under the same local load, I changed only that dispatch's QoS:
APITeststotal timeWithout load,
APITeststakes about 0.1 s on the current code. Fixing the delay needs an A/B Testing SDK change, so it's out of scope for this test-only PR.#no-changelog