1456027 - Addon enabled states not syncing correctly

Status: RESOLVED DUPLICATE of bug 1467904

(Firefox :: Sync, defect, P1)

Description

[Ryan Kelly [:rfkelly]]

Moved from https://github.com/mozilla/fxa-content-server/issues/6094, originally filed by Oana (cc'd).

---

Platform: Win 10, x64
Staging server [train 110] and production.

Steps to reproduce:

    Create two separate profiles: A & B.
    Log in on FxA with the same user.
    Add some extensions from addons.mozilla.com.
    Enable/Disable some add-ons on profile A.
    Sync between profile A & B.

Expected results:
The enabled/disabled state of the add-ons on profile A should appear in the Add-ons Manager of profile B.

Actual results:
Some add-ons are synced while some remain unchanged, not even transferred from profile A to B (in my example below, Facebook container and Swift Selection search).
See screenshot: https://www.screencast.com/t/01r8RWeYrw2e
Note: I've installed myself the 2 add-ons on the second profile too, but their state doesn't change after sync.

Comment 1

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

hrmph - I was mistaken - this bug isn't just about the enabled state, it's also about the addons not syncing at all. So it does seem likely that this bug and bug 1467904 are duplicates.

There's definitely quite a few strange things with how addon state/changes are tracked (but I can't see strangeness that would account for an addon install being missed entirely)

* The code has code which attempts to reconcile the actual state of addons with what Sync believes the state of the addons to be.

* The code also keeps a "change history" of addon state changes in the addonsreconciler.json file, and will consider changes >= our last sync date to be real changes and sync them. However:
** it's not clear why this is necessary given there's code that reconciles with the real addon state anyway - so this should be unnecessary.
** it keeps these changes for 7 days after the last sync date, which doesn't really make sense - why do they need to be kept after a sync.
** clearChangedIDs does *not* clear changes from that historical record and best I can tell it never did. Best I can tell, the normal tracker changes aren't actually used - but the addon tests all repeatedly call clearChangedIDs.
** it compares the server timestamp with a local timestamp, meaning clock skew will cause bad things to happen (although in this bug, we seem to be on the same machine, so that probably doesn't apply)
** Because it checks for >= the last sync date, it *always* uploads records twice

This code which keeps the historical changes landed in the very first bit of code which implemented addon syncing - bug 534956 - but that doesn't mention *why* it did that.

But even with all that weirdness, I still can't find a repo. I probably could by skewing my local clock. Hopefully we'll get some logs via bug 1467904, but I thought I'd note this as a reminder to myself later as I probably wont get to play more with this for a week or so.

Comment 2

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

(In reply to Mark Hammond [:markh] from comment #1)
> hrmph - I was mistaken - this bug isn't just about the enabled state, it's
> also about the addons not syncing at all.

Ah - but the only addon that's not syncing here is https://addons.mozilla.org/en-US/firefox/addon/swift-selection-search/ - and that happens to have the same configuration as bug 1476177, which is the root cause of bug 1467904.

So I'm going to morph this bug into "enabled states not synced" and leave the "entire addons not synced" to bug 1467904, as I'm now convinced they are 2 separate issues.

Comment 3

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

(In reply to Mark Hammond [:markh] from comment #2)
> Ah - but the only addon that's not syncing here is
> https://addons.mozilla.org/en-US/firefox/addon/swift-selection-search/ - and
> that happens to have the same configuration as bug 1476177, which is the
> root cause of bug 1467904.
> 
> So I'm going to morph this bug into "enabled states not synced" and leave
> the "entire addons not synced" to bug 1467904, as I'm now convinced they are
> 2 separate issues.

Just to flip-flop a (hopefully!) final time!

Bug 1476177 is in 60 and will also affect how we sync the enabled state. What this means is that an addon which was installed before Firefox 60 will have been correctly synced around different profiles. However, for some addons, after 60 we would have not synced anything about this addons around, including the enabled state.

IOW, many addons installed before Firefox 60 will exhibit failure to sync the enabled state.

So I'm going to close this as a dupe of bug 1467904, which is the bug that depends on the actual fix (bug 1476177).

Comment 4

[Stefan Deiac]

The issue it's reappeared on the Staging server [Train 126] but the production is not affected. I'll keep an eye and after the deploy, I'll retest it.

Comment 5

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

(In reply to Stefan Deiac from comment #4)
> The issue it's reappeared on the Staging server [Train 126] but the
> production is not affected. I'll keep an eye and after the deploy, I'll
> retest it.

This issue will not be impacted by the FxA server versions - any apparent correlation will be a coincidence.

Comment 6

[Stefan Deiac]

Retested the issue founded last week after the deploy of the Staging server [Train 126] and the issue doesn't occur on the latest version on Release. Due to that, I'll remove the NI from me, thanks.