fix(web): scope memory viewer navigation to the current memory (#790) - #791
Merged
Conversation
The memory viewer identifies its position by asset id alone: navigation round-trips through the URL and findMemoryAsset resolves the id to its first occurrence across all memories. Rule memories (e.g. birthday) can contain assets that also appear in on-this-day memories, so advancing past a duplicated asset snapped the viewer back to the earlier memory and looped forever. Carry the memory id through viewer URLs (memoryId query param) and prefer the occurrence inside that memory when resolving the position, falling back to the old first-match behavior for deep links.
Deeds67
added a commit
that referenced
this pull request
Jul 17, 2026
…#791) The memory viewer identifies its position by asset id alone: navigation round-trips through the URL and findMemoryAsset resolves the id to its first occurrence across all memories. Rule memories (e.g. birthday) can contain assets that also appear in on-this-day memories, so advancing past a duplicated asset snapped the viewer back to the earlier memory and looped forever. Carry the memory id through viewer URLs (memoryId query param) and prefer the occurrence inside that memory when resolving the position, falling back to the old first-match behavior for deep links.
Deeds67
added a commit
that referenced
this pull request
Jul 20, 2026
…#791) The memory viewer identifies its position by asset id alone: navigation round-trips through the URL and findMemoryAsset resolves the id to its first occurrence across all memories. Rule memories (e.g. birthday) can contain assets that also appear in on-this-day memories, so advancing past a duplicated asset snapped the viewer back to the earlier memory and looped forever. Carry the memory id through viewer URLs (memoryId query param) and prefer the occurrence inside that memory when resolving the position, falling back to the old first-match behavior for deep links.
Deeds67
added a commit
that referenced
this pull request
Jul 21, 2026
…#791) The memory viewer identifies its position by asset id alone: navigation round-trips through the URL and findMemoryAsset resolves the id to its first occurrence across all memories. Rule memories (e.g. birthday) can contain assets that also appear in on-this-day memories, so advancing past a duplicated asset snapped the viewer back to the earlier memory and looped forever. Carry the memory id through viewer URLs (memoryId query param) and prefer the occurrence inside that memory when resolving the position, falling back to the old first-match behavior for deep links.
Deeds67
added a commit
that referenced
this pull request
Jul 22, 2026
…#791) The memory viewer identifies its position by asset id alone: navigation round-trips through the URL and findMemoryAsset resolves the id to its first occurrence across all memories. Rule memories (e.g. birthday) can contain assets that also appear in on-this-day memories, so advancing past a duplicated asset snapped the viewer back to the earlier memory and looped forever. Carry the memory id through viewer URLs (memoryId query param) and prefer the occurrence inside that memory when resolving the position, falling back to the old first-match behavior for deep links.
Deeds67
added a commit
that referenced
this pull request
Jul 22, 2026
…#791) The memory viewer identifies its position by asset id alone: navigation round-trips through the URL and findMemoryAsset resolves the id to its first occurrence across all memories. Rule memories (e.g. birthday) can contain assets that also appear in on-this-day memories, so advancing past a duplicated asset snapped the viewer back to the earlier memory and looped forever. Carry the memory id through viewer URLs (memoryId query param) and prefer the occurrence inside that memory when resolving the position, falling back to the old first-match behavior for deep links.
Deeds67
added a commit
that referenced
this pull request
Jul 23, 2026
…#791) The memory viewer identifies its position by asset id alone: navigation round-trips through the URL and findMemoryAsset resolves the id to its first occurrence across all memories. Rule memories (e.g. birthday) can contain assets that also appear in on-this-day memories, so advancing past a duplicated asset snapped the viewer back to the earlier memory and looped forever. Carry the memory id through viewer URLs (memoryId query param) and prefer the occurrence inside that memory when resolving the position, falling back to the old first-match behavior for deep links.
Deeds67
added a commit
that referenced
this pull request
Jul 23, 2026
…#791) The memory viewer identifies its position by asset id alone: navigation round-trips through the URL and findMemoryAsset resolves the id to its first occurrence across all memories. Rule memories (e.g. birthday) can contain assets that also appear in on-this-day memories, so advancing past a duplicated asset snapped the viewer back to the earlier memory and looped forever. Carry the memory id through viewer URLs (memoryId query param) and prefer the occurrence inside that memory when resolving the position, falling back to the old first-match behavior for deep links.
Deeds67
added a commit
that referenced
this pull request
Jul 24, 2026
…#791) The memory viewer identifies its position by asset id alone: navigation round-trips through the URL and findMemoryAsset resolves the id to its first occurrence across all memories. Rule memories (e.g. birthday) can contain assets that also appear in on-this-day memories, so advancing past a duplicated asset snapped the viewer back to the earlier memory and looped forever. Carry the memory id through viewer URLs (memoryId query param) and prefer the occurrence inside that memory when resolving the position, falling back to the old first-match behavior for deep links.
Deeds67
added a commit
that referenced
this pull request
Jul 25, 2026
…#791) The memory viewer identifies its position by asset id alone: navigation round-trips through the URL and findMemoryAsset resolves the id to its first occurrence across all memories. Rule memories (e.g. birthday) can contain assets that also appear in on-this-day memories, so advancing past a duplicated asset snapped the viewer back to the earlier memory and looped forever. Carry the memory id through viewer URLs (memoryId query param) and prefer the occurrence inside that memory when resolving the position, falling back to the old first-match behavior for deep links.
ya4ept
pushed a commit
to ya4ept/Noodle_gallery
that referenced
this pull request
Jul 30, 2026
…noodle#790) (open-noodle#791) The memory viewer identifies its position by asset id alone: navigation round-trips through the URL and findMemoryAsset resolves the id to its first occurrence across all memories. Rule memories (e.g. birthday) can contain assets that also appear in on-this-day memories, so advancing past a duplicated asset snapped the viewer back to the earlier memory and looped forever. Carry the memory id through viewer URLs (memoryId query param) and prefer the occurrence inside that memory when resolving the position, falling back to the old first-match behavior for deep links.
Deeds67
added a commit
that referenced
this pull request
Aug 10, 2026
…#791) The memory viewer identifies its position by asset id alone: navigation round-trips through the URL and findMemoryAsset resolves the id to its first occurrence across all memories. Rule memories (e.g. birthday) can contain assets that also appear in on-this-day memories, so advancing past a duplicated asset snapped the viewer back to the earlier memory and looped forever. Carry the memory id through viewer URLs (memoryId query param) and prefer the occurrence inside that memory when resolving the position, falling back to the old first-match behavior for deep links.
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.
Fixes #790
Root cause
The memory viewer identifies its position by asset id alone: every next/previous action round-trips through the URL (
/memory?id=<assetId>), andfindMemoryAssetresolves that id to its first occurrence across all memories.Rule memories (e.g. birthday) can contain assets that also appear in on-this-day memories — a photo of the birthday person taken on this day in a past year is in both. Since rule memories have
memoryAt = today, they sort first in the lane. Advancing past a duplicated asset therefore snapped the viewer back into the earlier (birthday) memory, looping forever — exactly the reported "always loops after the 2-years-ago mark".This will matter even more once #789 (Tier 1 memory types) lands, since every new rule type multiplies cross-memory asset overlap.
Fix
Carry the memory id through viewer URLs (
memoryIdquery param) and prefer the occurrence inside that memory when resolving the viewer position, falling back to the old first-match behavior for deep links withoutmemoryId.Verification
findMemoryAssetduplicate-asset scoping + component tests for the URL wiring (watched fail pre-fix, pass post-fix)