Bugfix/noid/wrong images shown - #6635
Merged
Merged
Conversation
…sions Two different attachments sharing a display name (e.g. a generically named pasted screenshot) resolved to the same file inside the shared attachment cache directory. Since the media viewer prefetches the tapped image's neighbors, a colliding neighbor's download could overwrite the cache file the viewer had just shown, making the open image flip to a different one moments later. Cache files for the media viewer are now nested under a per-fileId subdirectory so same-named attachments can no longer collide. Assisted-by: Claude Code:claude-sonnet-5 Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Opening the first image of a group (or any image within the first two positions of the currently loaded media) triggered an older-history prefetch that prepends older items to the pager's item list and shifts the pager to compensate. That shift correction was emitted as a one-shot SharedFlow event, collected in a long-lived LaunchedEffect whose closure captured the item count from the composition active when the effect first launched. By the time the event fired, the item list had already grown, but the effect's clamp (`items.size` / later `pagerState.pageCount`) still reflected the stale, smaller count, so the pager settled on the wrong, small index - showing an unrelated, often much older image a moment after the tap. Moved the shift into UiState itself (MediaViewerViewModel.PendingShift) so the Compose side always applies it from the very same state snapshot as the already-updated item list, removing the possibility of a stale item count at the point the correction is applied. Assisted-by: Claude Code:claude-sonnet-5 Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
mahibi
force-pushed
the
bugfix/noid/wrongImagesShown
branch
from
September 3, 2026 09:10
c6101cd to
704697b
Compare
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.
Fix wrong image shown in media viewer
Fixes a bug where tapping an image in a chat's grouped image gallery opens the correct image briefly, then a second later flips to a completely different (often much older) image — reproducible
reliably by opening the first image of a group.
Root cause
The media viewer prefetches older conversation history whenever the tapped image sits within the first two positions of the currently-loaded media list (MediaViewerViewModel.loadOlderGroups()).
Once older items are fetched, they're prepended to the pager's item list, which shifts every existing index — the pager then needs to silently jump forward by that shift amount to keep the same
tapped image on screen.
That shift correction was emitted as a one-shot SharedFlow event, collected by a LaunchedEffect that launches once and lives for the screen's lifetime. Its body captured the item count
(items.size) from whatever composition was active when it first launched. By the time the shift event actually fired (after the older-items network fetch completed), the item list had already
grown, but the effect's clamp still used the stale, smaller count — so the pager settled on the wrong, small index instead of the correctly-shifted one, landing on an unrelated older image.
Fix
Moved the shift into MediaViewerViewModel.UiState itself as a PendingShift(id, amount) field, set atomically together with the prepended item list in the same state update. The Compose side now
reads it via LaunchedEffect(uiState.pendingShift?.id), so the item count and the shift always come from the same state snapshot, eliminating the stale-count race.
Also included: a related but separate hardening fix — the on-disk cache used for downloaded chat attachments (shared_attachments/) was keyed only by the sender-controlled, non-unique
file name. Two different attachments sharing a name (e.g. a generically-named pasted screenshot) could resolve to, and overwrite, the same cache file when downloaded concurrently. Cache files
used by the media viewer are now nested under a per-fileId subdirectory (shared_attachments//) so same-named attachments can no longer collide.
🏁 Checklist
/backport to stable-xx.x🤖 AI (if applicable)