Skip to content

Fix FeedListViewModelTest flakiness at its actual root cause (issue #261) - #296

Merged
mapitman merged 1 commit into
mainfrom
fix-feedlistviewmodeltest-flaky-261
Aug 6, 2026
Merged

Fix FeedListViewModelTest flakiness at its actual root cause (issue #261)#296
mapitman merged 1 commit into
mainfrom
fix-feedlistviewmodeltest-flaky-261

Conversation

@mapitman

@mapitman mapitman commented Aug 6, 2026

Copy link
Copy Markdown
Owner

Closes #261

Summary

Root-caused rather than contained (unlike the sibling ArticleListViewModelTest/SettingsViewModelTest flakiness, issues #54/#60/#215, where three separate root-cause attempts failed and a CI-only class skip was the only thing that stuck -- see repo history). Downloaded the actual CI failure artifacts from the run that failed this issue and found two distinct, understandable bugs:

  • uiState_splitsPodcastAndOtherFeedsIntoFixedSections failed with expected:<[2]> but was:<[]> -- its wait predicate was sections.any { isNotEmpty }, which only requires one of the two sections to have settled. Room delivers each subscribed feed's Flow update from its own background invalidation-tracker thread, so the sections can populate at different times, and the test could assert against a still-settling state. Fixed to wait for both feeds to have landed (sections.sumOf { it.feeds.size } == 2).
  • uiState_freezesUnreadCountWhileRefreshing failed with expected:<1> but was:<2> -- it (and a sibling test, uiState_allReadFeedWithNoNewItems_unreadCountNeverRisesDuringRefresh, same pattern) used a real 300ms MockResponse delay to keep the refresh coroutine genuinely in-flight while the test writes to the DB mid-refresh, racing real wall-clock time against the virtual test dispatcher -- exactly the failure mode a loaded CI runner exposes. Replaced with a MockWebServer Dispatcher blocked on a CountDownLatch the test releases explicitly instead of a real network response body reaching completion after a hoped-to-be-long-enough delay: same real dispatcher-switch mechanics (the network call still genuinely suspends on Dispatchers.IO), no more racing a fixed duration.

Test plan

)

Two distinct bugs, not generic CI noise:

- uiState_splitsPodcastAndOtherFeedsIntoFixedSections waited for
  `sections.any { isNotEmpty }`, which only requires one of the two
  sections to have settled. Room delivers each subscribed feed's
  Flow update from its own background invalidation-tracker thread,
  so the sections can populate at different times and the test could
  assert against a still-settling state. Wait for both feeds to have
  landed instead.

- uiState_freezesUnreadCountWhileRefreshing and
  uiState_allReadFeedWithNoNewItems_unreadCountNeverRisesDuringRefresh
  used a real 300ms MockResponse delay to keep the refresh coroutine
  genuinely in-flight while the test wrote to the DB, racing real
  wall-clock time against the virtual test dispatcher. Replace it
  with a MockWebServer Dispatcher blocked on a CountDownLatch the
  test releases explicitly -- same real dispatcher-switch mechanics,
  no more racing a fixed duration against CI runner load.
@mapitman
mapitman merged commit 918841a into main Aug 6, 2026
3 checks passed
@mapitman
mapitman deleted the fix-feedlistviewmodeltest-flaky-261 branch August 6, 2026 05:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

FeedListViewModelTest.uiState_freezesUnreadCountWhileRefreshing flaky on CI

1 participant