Flaky test: SettingsViewModelTest (intermittent, predates fork from myfeeds-android)

[mapitman]

SettingsViewModelTest has intermittently failed in CI at least twice, on different test methods, with a plain java.lang.AssertionError or kotlinx.coroutines.test.UncompletedCoroutinesError unrelated to the diff under test.

This predates this repo -- it was observed in myfeeds-android's CI before this repo was copied from it, so no run logs survive the copy and the specific failing method(s) aren't recorded. Filed here so the known pattern isn't lost, matching the other coroutine-timing races already tracked (issues #75, #76) and previously fixed elsewhere in this ViewModel family (issues #54/#60/#215).

Next time this reproduces in mycasts-android's own CI: capture the run URL and specific failing method name here before rerunning, so there's enough to actually root-cause it.

Workaround in the meantime: rerun locally 3-5x to confirm it's not a real regression, then gh run rerun <run-id> --failed.

[mapitman]

Investigated by temporarily removing the CI skip and running several isolated CI experiments (see PR #81, merged). Summary:

• The hang is still real in this repo's CI, not just a leftover from myfeeds-android.
• Isolated it to: addDefaultFeeds_importsBundledOpml (12 concurrent feed fetches) running before some other, otherwise-trivial test in the same class reliably triggers it. addDefaultFeeds itself always passes fast -- it's whatever runs after it, in the same Gradle test JVM fork, that hangs.
• Three rounds of teardown hygiene fixes (dedicated cancellable CoroutineScope for DataStore, explicit OkHttp dispatcher/connection-pool shutdown, dedicated Room executor instead of the shared ArchTaskExecutor) reduced but did not eliminate it -- the specific victim test shifted between runs.
• A thread-dump-on-hang watchdog showed every worker pool idle at the time of the hang, ruling out simple resource exhaustion. The test's own coroutine just never resumes -- consistent with a DataStore write never propagating back through settings: StateFlow, so a .first { ... } predicate waits on a condition that never becomes true.

Root-causing that specific propagation path is a bigger undertaking than made sense to keep pursuing right now, so the CI skip is back in place. Full findings are recorded in SettingsViewModelTest's class doc comment for whoever picks this up next -- it should save significant re-investigation time.

Leaving this open since it's not resolved.

[mapitman]

Reproduced repeatedly during this session's PR loop (2026-08-19/20) -- here's the evidence log #77 itself asked for.

Confirmed pattern, expanded scope: the flakiness isn't confined to `SettingsViewModelTest` -- `FeedListViewModelTest` hit it far more often in this repo's own CI. Every incident: exactly one test fails out of ~330+, always a different method, always `AssertionError` or `kotlinx.coroutines.test.UncompletedCoroutinesError`, always green on an immediate local rerun (5/5 in one case) and usually green on a CI rerun 1-2 attempts later.

CI incidents (run IDs from `gh run list --workflow=build.yml`), all on PRs with diffs unrelated to these test files:

• Run 32333041100 (PR Let a re-tapped download replace a wedged WorkManager job (issue #195) #204, branch `issue-195-adhoc-downloads-stuck-retry`): `FeedListViewModelTest` failed 3 consecutive attempts, three different methods (`deleteSelected_unsubscribesOnlySelectedFeedsAndExitsSelectionMode`, `dismissAddDefaultFeedsPrompt_marksShownWithoutImportingAnything`, `uiState_freezesUnreadCountWhileRefreshing`) -- admin-merged after confirming 5/5 local passes.
• Run 32336272859 (PR Stop double-reserving the navigation-bar inset on bottom-nav screens (issue #193) #207, branch `issue-193-double-nav-inset-gap`): `FeedListViewModelTest` failed 2 consecutive attempts (`deleteSelected_unsubscribesOnlySelectedFeedsAndExitsSelectionMode`, then `dismissAddDefaultFeedsPrompt_marksShownWithoutImportingAnything`) -- admin-merged.
• Run 32337281995 (PR Show each episode's download status in the Next Up queue (issue #192) #208, branch `issue-192-queue-download-status-icon`): `FeedListViewModelTest.acceptAddDefaultFeedsPrompt_marksShownAndImportsTheBundledFeeds` failed once, passed on CI rerun.
• Run 32340299272 (PR Include the currently-playing episode in the Next Up queue (issue #196) #210, branch `issue-196-currently-playing-in-queue`): `FeedListViewModelTest.dismissAddDefaultFeedsPrompt_marksShownWithoutImportingAnything` failed once, passed on CI rerun.
• Run 32382587766 (PR Make streaming cellular-aware instead of a blanket on/off toggle (issue #123) #215, branch `issue-123-cellular-aware-streaming`): `FeedListViewModelTest.dismissAddDefaultFeedsPrompt_marksShownWithoutImportingAnything` failed twice consecutively -- admin-merged.

Also observed locally (not CI, but same sandboxed/resource-constrained execution style) while iterating on PRs #211/#214: `SettingsViewModelTest.setUpdateIntervalMinutes_persistsAndReflectsInSettings` failed once with `UncompletedCoroutinesError`, passed immediately on rerun -- the exact symptom this issue was originally filed for.

What this rules out: not a bug in any one test's assertions or a missing `TrackedViewModelStore`/`cancelForTest()` teardown -- `FeedListViewModelTest` already has that pattern wired up correctly (checked directly). The randomness of which method fails, combined with it reproducing outside CI too, points toward genuine coroutine-dispatcher timing sensitivity under CPU contention (GitHub Actions' 2-core runners, and apparently this sandboxed dev environment too) rather than an isolation leak specific to one test file.

Suggested next step (not attempted here -- would need several expensive CI round-trips to verify, and I don't want to guess blind): try raising `kotlinx.coroutines.test`'s dead-man's-switch via the `kotlinx.coroutines.test.default_timeout` system property for the `testDebugUnitTest` task specifically. That would only address the `UncompletedCoroutinesError` half of the symptom, not the plain `AssertionError` half (which looks more like a StateFlow read racing its async update) -- so it's a partial mitigation candidate, not a confirmed fix.

Leaving this open with the fuller evidence trail now recorded, per the issue's own ask.