Avoid signing out of a device when renaming it

[MiSikora]

Task/Issue URL: https://app.asana.com/1/137249556945/project/1216103556496795/task/1217093845234581?focus=true
Tech Design URL (if applicable): https://app.asana.com/1/137249556945/project/1216103556496795/task/1216509582049467?focus=true
API Proposals URL(s) (if applicable): N/A

Description

I ran into this right after setting up sync on a fresh device. I renamed the device from the Sync settings, and when I returned to the screen the device was no longer synced. On a second device the renamed entry was still listed, and because this device had dropped out of the account I could sync it again, which left me with a duplicate and three devices in the list.

The rename does not use a dedicated endpoint. It re-authenticates the device, which issues a new sync token and replaces the one already stored. While that happens the app is still doing other authenticated work in the background, such as periodically refreshing the device list. If one of those requests is in flight with the old token at the moment it gets rotated, the server rejects it with an invalid credentials response. That response was treated as a signal that the account was gone, so the local sync data was cleared even though the account was still valid. Because nothing was actually removed on the server, the device kept appearing on other devices and syncing again created a duplicate.

This was less likely to happen before the Sync settings redesign. The rename used to be a dialog opened directly on the main Sync settings screen, so the rename and any refresh stayed on one screen. In the redesign the rename is confirmed on a separate screen, and the device list is refreshed when coming back to the main screen after the edit is confirmed. That return refresh lands right after the token is rotated, which makes the timing that triggers the bug much more likely.

The fix records which token each request used and compares it against the token currently stored when an invalid credentials response comes back. The local account is only cleared when the failing request used the token that is still current, or when the request carried no token at all. A rejection for a token that has since been replaced is treated as stale and ignored, so a rename no longer signs the device out. A genuine invalid credentials response for the current token still clears the account as before.

The behavior is behind the preventStaleTokenLogout flag, which is on by default.

Steps to test this PR

This was a race condition and is hard to reproduce reliably, so the steps below are a smoke test to confirm that renaming keeps the device synced.

Rename a device

• Set up Sync & Backup on a device.
• Tap the device in the list of synced devices.
• Tap "Edit Name".
• Enter a new name.
• Tap "Done".
• Verify the device is still synced and shows its new name.

UI changes

N/A

---

Note

Medium Risk
Changes when local sync credentials are cleared on 401, which affects session persistence; behavior is gated by a remote toggle and preserves clearing for the current token.

Overview
Fixes a race where renaming a device (re-login with a new sync token) could leave the device unsynced: a concurrent API call still using the old token could get 401 invalid credentials, and SyncServiceRemote would clearAll() local sync state as if the account were dead.

removeKeysIfInvalid now receives the token that failed (from the request Authorization header or explicit call-site token). It only wipes the store when that token still matches syncStore.token, or when the token is unknown (keeps prior behavior). A 401 on a superseded token is ignored when preventStaleTokenLogout is enabled (new toggle on SyncFeature, default true).

Tests cover current-token 401 (still clears), rotated-token 401 (no clear), and toggle-off (still clears).

^{Reviewed by Cursor Bugbot for commit e789f61. Bugbot is set up for automated code reviews on this repo. Configure here.}

[MiSikora]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Clean up sync code before integrating pixels #9386
• Avoid signing out of a device when renaming it #9374 👈 (View in Graphite)
• Handle simplified sync deep linking #9373
• Handle restore on reinstall sync scenario #9368
• Simplified sync UI updates #9363
• Handle v1 exchange sync codes #9362
• Handle sync recovery basic scenario #9356
• Add syncing with another device logic and navigation #9343
• Add generic handling of v1 sync errors #9337
• Add sync with another device UI #9334
• Detect scanned QR sync codes #9333
• Handle sync code pasting #9332
• Refactor simplified sync class names #9329
• Handle sync logic on the displayed QR code page #9328
• Display sync QR code in simplified sync #9321
• Make remove device dialog destructive #9317
• Mitigate sync settings UI race condtions #9316
• develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 6f60557. Configure here.}

[cursor]

Stale token 401 still triggers misleading signed-out notification

Medium Severity

The fix correctly prevents syncStore.clearAll() on a stale-token 401, but SyncInvalidTokenInterceptor — an OkHttp interceptor that fires on every sync-endpoint 401 — still shows a "signed out" notification for those same stale-token responses. After a rename, the device correctly stays synced, but the user receives a misleading "signed out" notification. The interceptor needs the same stale-token guard (compare request token against current stored token) to avoid this false notification.

 

^{Reviewed by Cursor Bugbot for commit 6f60557. Configure here.}

[MiSikora]

I'm not really sure if this should be fixed here. I'll create a follow up task in the backlog and update this comment once I do it.