FileStorageTests."Can parse mmol/L settings to mg/dL" fails intermittently when the full suite runs, and passes consistently in isolation.
✘ Test "Can parse mmol/L settings to mg/dL" recorded an issue at FileStorageTests.swift:139:9:
Expectation failed: (parsed?.threshold_setting → 5.5) == 100
Reproduction
- Full suite under
TEST_RUNNER_MallocScribble=1: 2 failures in 8 runs
-only-testing:TrioTests/FileStorageTests: 3/3 pass
MallocScribble is not required for the bug — it perturbs timing enough to surface it reliably enough to study.
What is known
The test saves Preferences with threshold_setting = 5.5 under OpenAPS.Settings.preferences, calls parseOnFileSettingsToMgdL(), and asserts the value was converted to mg/dL. On failure the first assertion (wasParsed == true) passes and only the re-read fails, having returned the pre-conversion value.
The whole path looks synchronous — save and retrieve both go through the same BaseFileStorage.processQueue via safeSync, and parseOnFileSettingsToMgdL calls save directly rather than saveAsync. So one of those assumptions must be wrong; Trio/Sources/Services/Storage/Disk/Disk.swift is the next place to look.
Ruled out
- Not
DeviceDataManager. It writes the same file (DeviceDataManager.swift:121, :217) and was the initial suspect, but gating TrioApp.loadServices() under XCTest locally still reproduced the failure.
- No other test writes that file —
OpenAPS.Settings.preferences appears in no other test source.
Why it matters beyond the flake
The test asserts on a real file in the app's shared Documents directory, written by a BaseFileStorage instance that other suites also construct, inside a process that is running the live app. Whatever the immediate mechanism, the isolation is worth fixing: a unit test should not be asserting on state that app code can also write.
FileStorageTests."Can parse mmol/L settings to mg/dL"fails intermittently when the full suite runs, and passes consistently in isolation.Reproduction
TEST_RUNNER_MallocScribble=1: 2 failures in 8 runs-only-testing:TrioTests/FileStorageTests: 3/3 passMallocScribbleis not required for the bug — it perturbs timing enough to surface it reliably enough to study.What is known
The test saves
Preferenceswiththreshold_setting = 5.5underOpenAPS.Settings.preferences, callsparseOnFileSettingsToMgdL(), and asserts the value was converted to mg/dL. On failure the first assertion (wasParsed == true) passes and only the re-read fails, having returned the pre-conversion value.The whole path looks synchronous —
saveandretrieveboth go through the sameBaseFileStorage.processQueueviasafeSync, andparseOnFileSettingsToMgdLcallssavedirectly rather thansaveAsync. So one of those assumptions must be wrong;Trio/Sources/Services/Storage/Disk/Disk.swiftis the next place to look.Ruled out
DeviceDataManager. It writes the same file (DeviceDataManager.swift:121,:217) and was the initial suspect, but gatingTrioApp.loadServices()under XCTest locally still reproduced the failure.OpenAPS.Settings.preferencesappears in no other test source.Why it matters beyond the flake
The test asserts on a real file in the app's shared Documents directory, written by a
BaseFileStorageinstance that other suites also construct, inside a process that is running the live app. Whatever the immediate mechanism, the isolation is worth fixing: a unit test should not be asserting on state that app code can also write.