1801295 - SyncedTabs.getRecentTabs not returning any tabs immediately after a quick write

Status: RESOLVED FIXED

(Firefox :: Sync, defect, P3)

Description

[Sarah Clements [:sclements]]

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?

Comment 1

[Sammy Khamis [:skhamis]]

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.

Comment 2

[Sarah Clements [:sclements]]

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?

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 4

[Sarah Clements [:sclements]]

Attachment: error-sync-1670342733550.txt

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.

Comment 5

[Sarah Clements [:sclements]]

Attachment: success-sync-1670343347180.txt

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

Comment 6

[Lougenia Bailey]

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

Comment 7

[Lougenia Bailey]

:sclements What were the profile changes you made?

Comment 8

[Sarah Clements [:sclements]]

(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.

Comment 9

[Mark Hammond [:markh] [:mhammond]]

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.

Comment 10

[Sam Foster [:sfoster] (he/him)]

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.

Comment 11

[Mark Hammond [:markh] [:mhammond]]

(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.

Comment 12

[Mark Hammond [:markh] [:mhammond]]

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.

Comment 13

[Mark Hammond [:markh] [:mhammond]]

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.

Comment 14

[Kelly Cochrane [:kcochrane]]

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

Comment 15

[Mark Hammond [:markh] [:mhammond]]

Attachment: Bug 1801295 (part 1) - add a test demonstrating how tabs aren't returned after a quickwrite. r?skhamis

Comment 16

[Mark Hammond [:markh] [:mhammond]]

Attachment: Bug 1801295 (part 2) - vendor new application-services with the fix. r?skhamis

Depends on D164781

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1a4abebe8ca8
(part 1) - add a test demonstrating how tabs aren't returned after a quickwrite. r=skhamis
https://hg.mozilla.org/integration/autoland/rev/aabdaccc5df9
(part 2) - vendor new application-services with the fix. r=skhamis

Comment 18

[Norisz Fay [:noriszfay]]

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

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 20

[Mark Hammond [:markh] [:mhammond]]

Attachment: Bug 1801295 (part 1) - add a test demonstrating how tabs aren't returned after a quickwrite.

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

Comment 21

[Mark Hammond [:markh] [:mhammond]]

Attachment: Bug 1801295 (part 2) - vendor the app-services vendor-mc/109 branch for the tabs fix.

Depends on D164993

Comment 22

[Phabricator Automation]

• 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

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

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)

Comment 24

[Ryan VanderMeulen [:RyanVM]]

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