I'm on latest nightly 109.0a1, signed in and I have 3 devices connected. When I went to the Firefox View page after updating, I see the "Nothing to see yet message" and upon investigating it's because the lazy.SyncedTabs.getRecentTabs is not returning any tabs. It's been at least 15-20 minutes, and despite trying to retrieve new tabs byrefreshing and hitting "sync" under my fx account in the hamburger menu.

Using the debugger, I can see that the "services.sync.tabs.changed" notifications in Firefox View are hitting the getSyncedTabData function but the SyncedTabs.getRecentTabs API keeps returning 0 tabs.

I saw this for a shorter period yesterday, running firefox locally, and noticed this in the console when this was happening "Final tab list has 0 clients with 0 tabs". But it seemed to recover after about 5-10 minutes so I thought it was a one-time glitch.

Sammy, has there been any recent changes to the API or engine that might've caused this to happen?

Hi Sarah,

Do you see any synced tabs in the synced tabs list? AFAIK, there have been no changes recently that would've tweaked that. I'm unable to reproduce this right now but will investigate a bit to see if there was any changes that could've caused this.

Also could you please post a few sync logs? Might give a bit of insight into what's happening behind the scenes here.

Lastly, there is a sync addon you could install https://addons.mozilla.org/en-US/firefox/addon/about-sync/ that looks into what the server sees for various collections -- might be helpful to see if there are tabs actually on the server and the client is not returning them for whatever reason.

Sorry for the delay, I was on vacation last week. I saw the same issue on Monday but now I'm seeing one tab show up there, from a local nightly build which is odd... because I've been consistently building nightly locally for dev work. Would it have returned 0 tabs based on a profile change?

The severity field is not set for this bug.
:lougenia, could you have a look please?

For more information, please visit auto_nag documentation.

I hit this issue again, and it looks like the stale tabs just aren't being returned via the getRecentTabs API (and one connected device was used 2 hours ago, a second one day ago). I saw a sync-error followed by several sync-success logs but still no tabs.

I've attached the latest sync-success log in case that's helpful.

:skhamis I'm going to mark this as a P3 but feel free to change it.

:sclements What were the profile changes you made?

(In reply to Lougenia Bailey from comment #7)

:sclements What were the profile changes you made?

I sometimes switch between fxa different accounts (i have two), but I don't recall changing the profile. And when I switched between the account not showing tabs, and the other account, I saw tabs on that second one. Switching back, I still didn't see tabs on my primary account.

Hi Sarah,
Unfortunately I can't see what might be going on here. My best guess is that there might be a bug in our stale device detection - as I note below, you have only 3 active FxA devices but over a hundred old "sync clients" - this dupe detection should handle that fine, but you might be hitting an edge-case rarely seen.

Unfortunately, the logs attached aren't complete enough to see a smoking gun. If you can reproduce this again, could you please make sure you upload all sync logs from when the browser restarted until the reproduction? The about:sync addon also allows you to gather all logs as a .zip file, which would be fine - we can identify browser restarts etc from the logs.

One thing that is very odd about your account is how many "stale" devices you have - according to FxA you have 3 devices connected to your account, but there are over 100 old client and tabs records! Due to a bug on mobile, the dupe mobile devices probably just reflect disconnecting and reconnecting, but if you explicitly disconnect and reconnect a desktop device it should be deleted from both the FxA device list and the clients list - but you have many duplicate desktop devices here. Are you explicitly disconnecting them, or is your workflow something like using a VM which you restore to a previous state before signing in again? If so, that's also expected and should not be a problem, I'm just trying to make sure something else bad isn't going on here that we should know about.

Its normal in desktop dev to have to clobber your development profile pretty frequently (via ./mach clobber), which might result in this many sync clients.

(In reply to Sam Foster [:sfoster] (he/him) from comment #10)

Its normal in desktop dev to have to clobber your development profile pretty frequently (via ./mach clobber), which might result in this many sync clients.

Ah yeah, the temp profile under obj-dir makes sense, thanks.

I finally see what's going on here - when we do a tabs "quick write" we end up deleting all rows from our database - so in the period between doing the quick-write and the next real tabs sync we end up returning no tabs.

https://github.com/mozilla/application-services/pull/5291 is a PR for 110, we'll probably need that commit in a branch we can uplift to 109. It's probably too late for 108.

Thanks for running this down and getting a PR out there, :markh!

Depends on D164781

https://hg.mozilla.org/mozilla-central/rev/1a4abebe8ca8
https://hg.mozilla.org/mozilla-central/rev/aabdaccc5df9

The patch landed in nightly and beta is affected.
:markh, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox109 to wontfix.

For more information, please visit auto_nag documentation.

Original Revision: https://phabricator.services.mozilla.com/D164781

Depends on D164993

• User impact if declined Synced tabs will not be shown for some period.
• Code covered by automated testing yes
• Fix verified in Nightly yes
• Needs manual QE test no
• Steps to reproduce for manual QE testing See bug
• Risk associated with taking this patch low
• Explanation of risk level risk is limited to synced tabs
• String changes made/needed none
• Is Android affected? no

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)

https://hg.mozilla.org/releases/mozilla-beta/rev/bb1a913c1860
https://hg.mozilla.org/releases/mozilla-beta/rev/d18e94a87a84