Skip to content

fix(extension-chrome): propagate remote title/URL edits to local tree#16

Merged
paperhurts merged 1 commit into
mainfrom
fix/remote-update-propagation
May 24, 2026
Merged

fix(extension-chrome): propagate remote title/URL edits to local tree#16
paperhurts merged 1 commit into
mainfrom
fix/remote-update-propagation

Conversation

@paperhurts
Copy link
Copy Markdown
Owner

Summary

When a remote bookmark already has a local mapping, applyRemoteChanges previously early-returned ("assume in sync; next reconcile fixes drift"). Remote title/URL edits made on Device B were invisible on Device A for up to an hour. The 5-min poll cycle now propagates them in seconds.

The fix: fetch the current local node via chrome.bookmarks.get, compare title/url against the remote entry, call chrome.bookmarks.update with only the changed fields. Both old and new URL are suppressed so the resulting onChanged echo doesn't bounce back to GitHub.

TDD log

  • RED: 3 new tests in apply-remote.test.ts:
    • Remote title change → chrome.bookmarks.update(nodeId, { title }) called
    • Remote URL change → chrome.bookmarks.update(nodeId, { url }) called
    • No-op when remote matches local → update NOT called
  • Watched 2/3 fail (the no-op test trivially passed because the original code never called update at all). Failures matched the documented bug exactly.
  • GREEN: added applyRemoteEdit helper that does the get → compare → suppress → update flow. All 12 apply-remote tests pass; full suite 72/72.

Test plan

  • pnpm test 72/72 (3 new for this fix)
  • pnpm typecheck clean
  • CI green

Closes #1

Previously applyRemoteChanges early-returned when a remote bookmark
was already in the local id map ('assume in sync; next reconcile
fixes drift'). A remote title or URL edit on Device B was invisible
on Device A for up to an hour, until the periodic reconcile re-walked
both sides.

When a remote bookmark already has a mapping, fetch the current local
node via chrome.bookmarks.get, compare title/url, and call
chrome.bookmarks.update with only the changed fields. Suppress both
the old URL (in case it's being changed away) and the new URL so the
resulting onChanged echo doesn't bounce back to GitHub.

The 5-minute poll cycle now propagates edits in seconds, not hours.

TDD: 3 new tests in apply-remote.test.ts (title change → update, URL
change → update, no-op when matching → no update). Watched 2/3 fail
RED (skip-no-op already passed because original code never called
update). Implementation added a new applyRemoteEdit helper; all
12 apply-remote tests + full suite (72) pass GREEN.

Closes #1
@paperhurts paperhurts merged commit 75d51e4 into main May 24, 2026
1 check passed
@paperhurts paperhurts deleted the fix/remote-update-propagation branch May 24, 2026 04:07
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.

apply-remote: skipping remote updates causes ~1h propagation lag for title/URL edits

1 participant