Repository navigation
Keep the shop detail's tag fetch out of the item tag list - #98
Merged
Merged
Conversation
ItemTagRepository.fetchAll (the shop detail's fetch) stored its result in itemTags, the item tag list's pages. When it answered after the user had gone on to another shop's item tag list, that list showed the previous shop's tags. Seen on the iPhone against the local API: shop A's detail still loading while shop B's list opened left A's tags in B's list. The shop detail keeps the tags itself, so fetchAll now only returns them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K5hZEFqXhBsUQwSWsgR6eH
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
1 participant
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.
Why
Verifying the item tag screens on the iPhone against the local API showed that the item tag list can show another shop's tags.
ItemTagRepository.fetchAll(shopId:)is the shop detail's fetch, but it also stored its result initemTags, which is the item tag list's paged list. When the shop detail of shop A was still loading (or reloading after completing / idling a tag) while the user went on to shop B's item tag list, A's answer arrived last and replaced B's list. The generation guard added earlier only coversreloadPage/loadNextPage.On the device (temporary on-device test with the real repository and view models against the local API, shops "Verify A" / "Verify B" with 12 tags each): shop A's detail reload started, then shop B's item tag list reload → B's list showed A's tags in 4 of 5 rounds. Switching between lists (A's list interrupted by B's) and between the two shop details was already correct.
Change
fetchAll(shopId:)only returns the tags; the shop detail keeps them itself (ShopDetailViewModel.itemTags), so it no longer touches the list'sitemTags. Nothing else read the list afterfetchAll.Tests
ItemTagRepositoryPaginationTest.previousShopsDetailFetchDoesNotReplaceAnotherShopsList(local HTTP server holding shop A's answer): B's list keepsb1and B's meta after A's latefetchAllanswer, andfetchAllstill returns A's tags.repository.itemTags.map(\.id) == ["b1"]got A's tags); passes with the fix.Local checks
make lint: 0 violations, 0 files need formattingDevice check (local API)
ShopCreateViewrendered on the device shows the default zone "(GMT+09:00) Tokyo" (Utility.currentTimeZone()matched a picker tag); after selecting "Hawaii" the row shows "(GMT-10:00) Hawaii", and Save created the shop withtime_zone = "Hawaii"in the DB. XCUITest could not be used on this device (UI automation can't be enabled), so the picker selection was set through its binding rather than by a tap.🤖 Generated with Claude Code
https://claude.ai/code/session_01K5hZEFqXhBsUQwSWsgR6eH