From 39cbad522edbe3b95f502ccc8b72af520ebe80f2 Mon Sep 17 00:00:00 2001 From: choiminyeong Date: Sat, 29 Aug 2026 19:42:08 +0900 Subject: [PATCH] TASK-041: fix favorite star reverting after switching tabs toggleFavorite kept starredCoordinatesCache in sync with a successful star/unstar but never patched repositorySnapshots (the per-mode full-repository-list cache), so a starred repository's count reverted to its pre-toggle cached value on the next visit to that mode, and a newly-starred repository could be silently missing from an already-cached favorites list. Fix: two new helpers (adjustCachedStarCounts, removeFromCachedSnapshot) patch every cached snapshot containing the toggled repository, and a star invalidates just the FAVORITES snapshot key if already cached. Chosen over a full cache-clear-and-refetch after live testing showed Gitea's own starsCount can lag slightly behind a star/unstar on its plain repository-listing endpoint. Also fixes a related gap: unstarring from the FAVORITES tab wasn't updating starredCoordinatesCache at all (only the two ALL-mode branches were). Two new regression tests; all existing tests pass unmodified. Build/test/lint green, live-verified on device. Co-Authored-By: Claude Sonnet 5 --- .../repositories/RepositoryListViewModel.kt | 49 +++++++- .../RepositoryListViewModelTest.kt | 49 ++++++++ docs/development-log.md | 48 ++++++++ ...-favorite-star-reverts-after-tab-switch.md | 113 ++++++++++++++++++ 4 files changed, 255 insertions(+), 4 deletions(-) create mode 100644 tasks/041-favorite-star-reverts-after-tab-switch.md diff --git a/app/src/main/java/com/ubisam/ubgitea/feature/repositories/RepositoryListViewModel.kt b/app/src/main/java/com/ubisam/ubgitea/feature/repositories/RepositoryListViewModel.kt index 7b1f722..ec4ac37 100644 --- a/app/src/main/java/com/ubisam/ubgitea/feature/repositories/RepositoryListViewModel.kt +++ b/app/src/main/java/com/ubisam/ubgitea/feature/repositories/RepositoryListViewModel.kt @@ -319,19 +319,37 @@ class RepositoryListViewModel( when { alreadyStarredThisSession -> { favoritesApi.unstar(repository.coordinates) - // Keeps loadStarredCoordinatesOnce's cache consistent with what actually - // happened, without a network round trip just to confirm it -- only touches - // the cache when it's already populated; if it isn't, the next ALL-list load - // fetches a fresh one anyway. + // Keeps loadStarredCoordinatesOnce's cache, and every cached repositorySnapshots + // page that includes this repository, consistent with what actually happened -- + // without a network round trip just to confirm it. Deliberately a local patch, not + // a cache-clearing forced refetch: Gitea's own starsCount for a repository was + // observed live to lag slightly behind a star/unstar (the /user/starred listing + // reflected a toggle before the plain repository listing did), so trusting a fresh + // fetch immediately after this call risks showing a value that undercounts what we + // already know just happened. A repository this session knows is no longer starred + // is also dropped from any cached FAVORITES snapshot, so that list stays consistent + // the next time it's opened without a repeat network call either. starredCoordinatesCache = starredCoordinatesCache?.minus(repository.coordinates) + adjustCachedStarCounts(repository.coordinates, delta = -1) + removeFromCachedSnapshot(RepositoryListMode.FAVORITES, organization = null, repository.coordinates) } mode == RepositoryListMode.ALL -> { favoritesApi.star(repository.coordinates) starredCoordinatesCache = starredCoordinatesCache?.plus(repository.coordinates) + adjustCachedStarCounts(repository.coordinates, delta = +1) + // The FAVORITES snapshot can't be surgically patched the same way (adding a row + // needs a full RepositorySummary this call site doesn't have) -- if it's already + // cached from an earlier visit this session, invalidate just that one entry so the + // next visit fetches it fresh and picks up the new star, rather than leaving it + // silently missing. + repositorySnapshots.remove(RepositorySnapshotKey(RepositoryListMode.FAVORITES, null)) } else -> { favoritesApi.unstar(repository.coordinates) removeRow(repository.coordinates) + starredCoordinatesCache = starredCoordinatesCache?.minus(repository.coordinates) + adjustCachedStarCounts(repository.coordinates, delta = -1) + removeFromCachedSnapshot(RepositoryListMode.FAVORITES, organization = null, repository.coordinates) } } } catch (failure: Throwable) { @@ -535,6 +553,29 @@ class RepositoryListViewModel( return loaded.also { repositorySnapshots[key] = it } } + // Keeps every cached repositorySnapshots page that includes this repository showing the right + // starsCount after a star/unstar this session already confirmed happened -- otherwise a repository + // whose page was fetched before the toggle (e.g. the ALL list loaded once at app start) would keep + // showing its pre-toggle count on every later visit to that mode, since loadRepositorySnapshot + // only fetches once per key and then reuses whatever's cached. + private fun adjustCachedStarCounts(coordinates: RepositoryCoordinates, delta: Int) { + for ((key, page) in repositorySnapshots) { + if (page.none { it.coordinates == coordinates }) continue + repositorySnapshots[key] = page.map { + if (it.coordinates == coordinates) it.copy(starsCount = (it.starsCount + delta).coerceAtLeast(0)) else it + } + } + } + + // Drops a repository from one cached snapshot (used for the FAVORITES list after this session + // confirms it's no longer starred) rather than clearing the whole cache -- the row itself doesn't + // need to be re-added anywhere else on unstar, since ALL/organization listings show every + // repository regardless of starred state. + private fun removeFromCachedSnapshot(mode: RepositoryListMode, organization: String?, coordinates: RepositoryCoordinates) { + val key = RepositorySnapshotKey(mode, organization) + repositorySnapshots[key]?.let { page -> repositorySnapshots[key] = page.filterNot { it.coordinates == coordinates } } + } + private suspend fun loadOrganizationsOnce(): List { cachedOrganizations?.let { return it } val loaded = try { diff --git a/app/src/test/java/com/ubisam/ubgitea/feature/repositories/RepositoryListViewModelTest.kt b/app/src/test/java/com/ubisam/ubgitea/feature/repositories/RepositoryListViewModelTest.kt index 547b9f1..b0a4cb9 100644 --- a/app/src/test/java/com/ubisam/ubgitea/feature/repositories/RepositoryListViewModelTest.kt +++ b/app/src/test/java/com/ubisam/ubgitea/feature/repositories/RepositoryListViewModelTest.kt @@ -357,6 +357,55 @@ class RepositoryListViewModelTest { assertEquals(FavoriteActionUiState.Idle, reloaded.favoriteAction) } + @Test + fun `starring a repository keeps its incremented count after switching to favorites and back`() = runTest(dispatcher.scheduler) { + // Reproduces a live bug report: starring from the all-repositories list, visiting the + // favorites tab, then coming back showed the star filled but the count reverted to its + // pre-toggle value -- loadRepositorySnapshot caches the ALL page for the rest of the + // session, so switching modes and back was reusing that stale, never-repatched snapshot + // instead of the count toggleFavorite already knew was right. + val browser = FakeBrowser(repositories = listOf(page1Of(repo("repo", starsCount = 0)))) + val viewModel = viewModel(browser) + advanceUntilIdle() + + val row = (viewModel.state.value as RepositoryListUiState.Content).repositories.single() + viewModel.toggleFavorite(row) + advanceUntilIdle() + + viewModel.showFavorites() + advanceUntilIdle() + viewModel.showAllRepositories() + advanceUntilIdle() + + val reloaded = (viewModel.state.value as RepositoryListUiState.Content).repositories.single() + assertEquals(FavoriteActionUiState.Starred, reloaded.favoriteAction) + assertEquals(1, reloaded.starsCount) + } + + @Test + fun `un-starring keeps its decremented count after switching to favorites and back`() = runTest(dispatcher.scheduler) { + val browser = FakeBrowser( + repositories = listOf(page1Of(repo("repo", starsCount = 4))), + starred = listOf(page1Of(repo("repo", starsCount = 4))), + ) + val viewModel = viewModel(browser) + advanceUntilIdle() + val row = (viewModel.state.value as RepositoryListUiState.Content).repositories.single() + assertEquals(FavoriteActionUiState.Starred, row.favoriteAction) + + viewModel.toggleFavorite(row) + advanceUntilIdle() + + viewModel.showFavorites() + advanceUntilIdle() + viewModel.showAllRepositories() + advanceUntilIdle() + + val reloaded = (viewModel.state.value as RepositoryListUiState.Content).repositories.single() + assertEquals(FavoriteActionUiState.Idle, reloaded.favoriteAction) + assertEquals(3, reloaded.starsCount) + } + @Test fun `starring a repository from the all-repositories list marks it starred without removing it`() = runTest(dispatcher.scheduler) { val browser = FakeBrowser(repositories = listOf(page1Of(repo("repo")))) diff --git a/docs/development-log.md b/docs/development-log.md index e21b13a..987ce7a 100644 --- a/docs/development-log.md +++ b/docs/development-log.md @@ -797,3 +797,51 @@ This is the append-only implementation and handoff record shared by Codex and Cl - Next recommended task: continue the broader design-review pass (work-item/PR detail views with real content, file viewers) from where TASK-039 left off. - Next owner: Claude, continuing per the standing direction. + +## 2026-08-29 (continued) — TASK-041: favorite star reverted / missing from favorites after tab switch + +- Agent and role: Claude, direct continuation of the same live session. Live bug report mid-turn while + reviewing another screen: "즐겨찾기 누르고나면 카운팅은 되는데 즐겨찾기 탭에 가면 방금 누른 항목이 + 안떠있다. 그리고 다시 원래 탭인 레포지토리로 가보면 다시 즐겨찾기가 풀려있어." Paused the in-progress + work and switched to reproducing and fixing this immediately, per the standing priority of live bug + reports over open-ended review work. +- Commit/diff: on `claude/task-015-notifications`; `RepositoryListViewModel.kt`'s `toggleFavorite` + reworked to patch `repositorySnapshots` (not just `starredCoordinatesCache`) on every successful + star/unstar; two new tests in `RepositoryListViewModelTest.kt`; + `tasks/041-favorite-star-reverts-after-tab-switch.md`. +- Root cause: `repositorySnapshots` (the per-mode full-repository-list cache, fetched once per session + and reused on every later visit to that mode) was never patched by `toggleFavorite` — only the + separate `starredCoordinatesCache` was. So the star icon correctly showed filled (from the patched + cache), but the displayed `starsCount` reverted to whatever was cached from the very first load of + that mode, and a favorites tab already cached from an earlier visit kept silently missing a + newly-starred repository. +- How it was diagnosed: reproduced live on-device (star a repository, switch to 즐겨찾기, switch back — + watched the star/count go wrong exactly as reported). Added temporary debug-only `Log.w` logging of + the star/unstar HTTP response directly in `GiteaRepositoryBrowserApi` to rule out a failed request — + confirmed `HTTP 204` (success) every time, isolating the bug to client-side caching, not the network + call. Removed the temporary logging once the root cause was confirmed. +- How it was fixed: tried a "clear the whole cache on every toggle, force a refetch" approach first; + reverted after live testing showed Gitea's own starsCount on the plain repository-listing endpoint + lags slightly behind a star/unstar (the /user/starred listing reflected a toggle sooner) — forcing a + refetch would trade one race condition for another. Switched to a local patch instead: two new + private helpers (`adjustCachedStarCounts`, `removeFromCachedSnapshot`) keep every cached snapshot + that includes the toggled repository consistent with what the app already knows happened, without a + network round trip. A star also invalidates just the FAVORITES snapshot key if it was already cached + (can't surgically insert a row without a full domain object at that call site) so the next visit + fetches it fresh instead of silently missing the new star. +- Files changed: `feature/repositories/RepositoryListViewModel.kt`, + `feature/repositories/RepositoryListViewModelTest.kt` (test file, actually under + `app/src/test/java/...`), `tasks/041-favorite-star-reverts-after-tab-switch.md`. +- Checks and results: `./gradlew compileDebugKotlin compileDebugUnitTestKotlin testDebugUnitTest assembleDebug lintDebug` + BUILD SUCCESSFUL, every pre-existing favorite-toggle test passing unmodified plus two new regression + tests, 0 lint errors. +- Live verification: installed over wireless `adb`. Starred a never-before-touched repository + (`LGD-AP4-RPR`) from the ALL tab, confirmed it appeared in 즐겨찾기 (★1), switched back to 전체 + 저장소 and confirmed the star/count stayed correct (★1) instead of reverting — screenshots at each + step. +- Review findings and resolutions: None from a separate review pass. +- Known limitations: None outstanding for this task. +- Next recommended task: resume the design-review pass (TASK-039's known limitations: work-item/PR + detail views with real content, file viewers, extended dark-mode coverage) from where it was paused + for this bug fix. +- Next owner: Claude, continuing per the standing direction. diff --git a/tasks/041-favorite-star-reverts-after-tab-switch.md b/tasks/041-favorite-star-reverts-after-tab-switch.md new file mode 100644 index 0000000..050cc79 --- /dev/null +++ b/tasks/041-favorite-star-reverts-after-tab-switch.md @@ -0,0 +1,113 @@ +# TASK-041: Favorite star reverted / missing from favorites after switching tabs + +Status: implemented; all required checks pass; live-confirmed on the human product owner's device +Owner: Claude +Reviewer: Codex + +## Outcome + +Live bug report: "즐겨찾기 누르고나면 카운팅은 되는데 즐겨찾기 탭에 가면 방금 누른 항목이 안떠있다. +그리고 다시 원래 탭인 레포지토리로 가보면 다시 즐겨찾기가 풀려있어" (starring a repository counts up, +but it doesn't show up on the favorites tab, and going back to the repository tab the star looks +undone again). + +Root cause: `RepositoryListViewModel` caches each mode's full repository list once per session +(`repositorySnapshots`, keyed by mode/organization) and reuses it on every later visit to that mode +without refetching. `toggleFavorite`'s success path already kept a *second*, separate cache +(`starredCoordinatesCache`, used only for the ALL list's "is this already starred" cross-reference) in +sync with a successful star/unstar — but never touched `repositorySnapshots` itself. So after starring +a repository from the ALL tab: the star icon correctly showed filled (from the patched +`starredCoordinatesCache`), but its `starsCount` reverted to whatever `repositorySnapshots` had cached +from the very first ALL-tab load, before the star happened — and the FAVORITES tab, if its snapshot was +already cached from an earlier visit, kept showing its own pre-star list, silently missing the new +star. Confirmed live: the actual `PUT /api/v1/user/starred/...` call was succeeding (`HTTP 204`, added +temporary debug logging to verify), and Gitea's `/user/starred` listing reflected the toggle almost +immediately, but its plain repository-listing endpoint (`/user/repos`) was observed to lag behind on +`starsCount` for a bit — both real UI symptoms trace to this same repositorySnapshots gap. + +## Scope + +- Included: `feature/repositories/RepositoryListViewModel.kt`'s `toggleFavorite` — patches + `repositorySnapshots` (not just `starredCoordinatesCache`) on every successful star/unstar; two new + private helpers (`adjustCachedStarCounts`, `removeFromCachedSnapshot`); the FAVORITES-mode unstar + branch now also updates `starredCoordinatesCache` (previously only the ALL-mode branches did). +- Excluded: no change to how `repositorySnapshots`/`starredCoordinatesCache` are populated or + invalidated elsewhere (`refreshRepositories()`, `logout()` already clear both correctly — untouched). + No change to the actual star/unstar HTTP calls themselves (confirmed already correct). + +## Design notes + +- **A local patch, not a cache-clearing forced refetch.** The tempting alternative — just call + `repositorySnapshots.clear()` on every successful toggle, forcing a fresh fetch next time each mode + is opened — was tried first and reverted after live testing showed Gitea's own `starsCount` on the + plain repository-listing endpoint lags slightly behind a star/unstar (the `/user/starred` listing + reflected a toggle before the plain repository listing did). Forcing a refetch would trade one race + condition (a frozen-forever local cache) for another (trusting a server response that hasn't caught + up yet) — and would have undone this app's own established "the client already knows the truth, + don't wait on the server to agree" philosophy from TASK-034's optimistic-UI fix. Patching the cached + count directly, the same way `starredCoordinatesCache` was already being patched, keeps the display + correct immediately and doesn't depend on Gitea's timing at all. +- **The FAVORITES snapshot's *membership* (not just count) is different**: removing a repository from + a cached FAVORITES snapshot on unstar is a simple filter (`removeFromCachedSnapshot`) since no new + data is needed. Adding one on star can't be done the same way — inserting a row into that cached list + would need a full `RepositorySummary`, which `toggleFavorite` only has as a `RepositoryRowUiModel` (a + UI projection, not the domain type, and not guaranteed to carry every field). Rather than + reconstructing one and risking a subtly-wrong synthetic entry, a star instead invalidates just the + FAVORITES snapshot key (`repositorySnapshots.remove(...)`) if it was already cached, so the next + visit fetches it fresh — a single, targeted extra network call only when that specific list was + already stale, not a blanket invalidation of everything. +- **`starredCoordinatesCache` now updates on the FAVORITES-mode unstar branch too.** It previously only + updated on the two ALL-mode branches — a real, separate gap: unstarring from the FAVORITES tab left + the ALL tab's "already starred" cross-reference stale for that repository until the next full + session-cache invalidation. + +## Acceptance criteria + +- [x] Starring a repository from the ALL tab, then switching to FAVORITES, shows the newly-starred + repository there (not silently missing). +- [x] Switching back to ALL after that shows the correct, incremented star count — not reverted to the + pre-toggle cached value. +- [x] Unstarring (from either tab) keeps the count/membership consistent across the same round trip. +- [x] Every existing favorite-toggle test still passes unmodified. +- [x] Two new regression tests cover the exact reported scenario (star-then-switch-tabs-and-back, + unstar-then-switch-tabs-and-back), both asserting the count stays correct after the round trip. +- [x] Build, unit tests, and lint pass. +- [x] Live-confirmed on the human product owner's device: starred a never-before-touched repository, + confirmed it appeared correctly in 즐겨찾기, switched back to 전체 저장소, confirmed the star and + count (★1) both stayed correct instead of reverting. + +## Required checks + +```text +./gradlew compileDebugKotlin compileDebugUnitTestKotlin testDebugUnitTest assembleDebug lintDebug +``` + +## Evidence + +- `feature/repositories/RepositoryListViewModel.kt`: `toggleFavorite`'s three success branches now + each patch `repositorySnapshots` via the new `adjustCachedStarCounts`/`removeFromCachedSnapshot` + helpers, alongside the existing `starredCoordinatesCache` patch (now present on all three branches, + not just the two ALL-mode ones). +- `RepositoryListViewModelTest.kt`: two new tests — `starring a repository keeps its incremented count + after switching to favorites and back` and `un-starring keeps its decremented count after switching + to favorites and back` — plus every pre-existing favorite-toggle test (increment, repeat-tap-toggle, + round-trip, immediate-optimistic-update, rollback-on-failure for both directions, the existing + already-session-known-starred-cache test) passing unmodified. +- Live debugging: temporarily added debug-only `Log.w` logging of the star/unstar HTTP status directly + in `GiteaRepositoryBrowserApi.star`/`unstar` to confirm the actual server response + (`HTTP 204`, i.e. success) before concluding the bug was client-side caching, not a failed request; + removed once the root cause was confirmed. +- `./gradlew compileDebugKotlin compileDebugUnitTestKotlin testDebugUnitTest assembleDebug lintDebug`: + BUILD SUCCESSFUL, all unit tests passing (including the two new ones), 0 lint errors. +- Live device: installed over wireless `adb`. Starred `LGD-AP4-RPR` (a repository never previously + touched this session) from the ALL tab (screenshot: ★1). Switched to 즐겨찾기 — confirmed it appears + there (screenshot: ★1, alongside the other already-starred repositories). Switched back to 전체 + 저장소 — confirmed it still shows ★1, not reverted to ☆0/★0 as before the fix (screenshot). + +## Known limitations + +None outstanding for this task. + +## Review findings + +None yet — pending Codex/human review.