Repository navigation
Keep a slow critical event log export from failing other tests - #2622
Merged
Merged
Conversation
On CI the full export in testExportPartial sometimes runs past the 10 s wait. Its completion handler then fires after tearDown, so its asserts land on whichever test is running and the IUO properties it reads are nil, which crashes the test process. In LoopKit/LoopWorkspace#566's runs 1320 and 1321 the export finished about 18 s in, right after the LoopTests bundle ended. The handlers now only record the error; the checks run after the wait, and the wait is 60 s.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CriticalEventLogExportManagerTests.testExportPartialfailed CircleCI runs 1320 and 1321 for LoopKit/LoopWorkspace#566, and the export tests failed the same way on 1310 and 1312.The full export runs on a background queue. On CI it sometimes runs past the test's 10 s wait. On 1321 it finished about 18 s after it started, right after the LoopTests bundle ended. When that happens:
testExportPartialon 1310)self.fileManager, whichtearDownhas set to nil, and crashes the test processThe handlers now only record the error. Each test checks the result after its wait, and the wait is 60 s. A passing run still takes well under a second.
The slowness itself looks like thread starvation in the test host. In 1321's crash report, 6 threads are blocked on a semaphore in
HealthStoreUnitCache.getHealthStoreUnitAndUpdateCache(for:), called fromLiveActivityManager.update()tasks. Each waits up to 3 s for HealthKit preferred units. That's left for a separate change.Tested on the simulator:
DeviceDataManagerTests, which runs next, passes