If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

No initial sync after migration until restart



Cloud Services
Firefox Sync: Backend
6 years ago
6 years ago


(Reporter: zandr, Unassigned)


Firefox Tracking Flags

(Not tracked)



(4 attachments)



6 years ago
Created attachment 565823 [details]
Failure (Yellow Bar) immediately after migration.

My account was recently migrated. On the first sync after migration, I got a yellow bar.

The next sync seemed normal enough, it got the new node and uploaded history and tabs. However, since this was a migration, an initial sync should have happened. View Quota confirmed that I had no passwords, bookmarks, or prefs, and only a small amount of data in history and tabs.

Brief chat with petef suggested that there might be a client bug that requires a restart in this case, but also that memcache hadn't been flushed yet, so my client might not know the data is gone.

I closed (sleep) my machine and went to dinner, and saw the same behavior when I returned.

I remembered petef's comment about restarting the Firefox, and did so. First sync after the restart was an initial sync, and View Quota looks normal now.

Logs attached.

Comment 1

6 years ago
Created attachment 565824 [details]
Success after migration (gets new node) and incremental sync

Comment 2

6 years ago
Created attachment 565825 [details]
Typical incremental sync

This is typical of incremental syncs that followed, up until the restart.

Comment 3

6 years ago
Created attachment 565826 [details]
First sync after restart: initial sync
info/collections is stored in memcache. Without a flush, the client won't know that data has disappeared, and will continue doing incremental syncs. This is expected. What is unexpected is if the memcache wipe happens, the client downloads an empty info/collections at the start of a sync, and does *not* do an initial sync. That did not occur here.

Attachment 565824 [details] shows that info/collections, meta/global, and pretty much everything is all still available after reassignment. An incremental sync occurs.

This continues throughout all of the logs; info/collections is never empty. In fact, the *only* reason you're getting an first sync after restart is because we don't cache your keys in persistent storage on the client. The client starts up, the server reports that all is well and full of data, but we get a 404 fetching keys. See:

  INFO	Testing info/collections: {... "crypto":1317891307.02, ...}
  WARN	Got 404 for crypto/keys, but 'crypto' in info/collections. Regenerating.

Thanks to remediation work for Bug 664865, this causes the client to strive for consistency by generating new keys and wiping the server, which results (naturally) in a fresh start. At no point does it appear that your info/collections record was wiped during migration, and thus a client with locally cached keys will never do a fresh start.

tl;dr: it doesn't look like memcache was wiped after you were reassigned. The client is behaving as expected. We are lucky that Fx7 and above will essentially do the wipe from the client when it sees keys are missing.

Leaving this bug open for a little while in case ops wants to comment.
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [closeme 2011-10-30]

Comment 5

6 years ago
Resolved per whiteboard
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2011-10-30]
You need to log in before you can comment on or make changes to this bug.