User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20160502160818

I've seen this error in another log but can't recall a bug being on file for it. > 1462775779342 Sync.Store.Addons WARN Encountered exception: Error: Add-on not found after install: tabimprovelite@mozillaonline.com (resource://gre/modules/services-sync/engines/addons.js:311:1) JS Stack trace: create@addons.js:311:1 < Store.prototype.applyIncoming@engines.js:337:7 < ... > ... > 1462775779372 Sync.Engine.Addons ERROR null

I looks like tabimprovelite was replaced by tabtweak : https://github.com/MozillaOnline/tabtweak/blob/develop/components/tabTweak.js#L29 I tested tabtweak on Firefox release/nightly and the error didn't appear because the addon wasn't synced at all (is this intended?).

Actually after re-reading this code it's the other way around, if tabimprovelite is installed tabtweak is uninstall, but if tabimprovelite is disabled, they uninstall it..

(In reply to Edouard Oger [:eoger] from comment #2) > I tested tabtweak on Firefox release/nightly and the error didn't appear > because the addon wasn't synced at all (is this intended?). ... > Actually after re-reading this code it's the other way around, if > tabimprovelite is installed tabtweak is uninstall, but if tabimprovelite is > disabled, they uninstall it.. It sounds like that answers your question (ie, you are no longer surprised it doesn't appear to have synced, right?) I guess another question then becomes "what is the right thing to do in this case?". At face value, it seems like we should be treating the deletion as a real deletion - but we will not do that IIUC as we are ignoring tracker changes because we are syncing. I'm not sure how hard it would be to actually implement this, but it almost sounds like the correct approach would be: * change the tracker so it never stops listening, but give it enough smarts to know when Sync is explicitly doing something with an addon and ignore that. * after the install of the addon check the tracker - if it is now treated as deleted just skip that additional check - the next sync should write the deleted record. ie, the flow might be something like: * Sync installs addon-1. * Sync tracker sees this install of addon-1 but ignores it as Sync has somehow told it that the operation was directly by Sync. * Somehow as part of this process addon-1 is deleted. * Tracker *does not* ignore this as Sync hasn't told it is deleting the addon. * Sync tracker marks addon-1 as deleted. * Initial install of addon-1 completes. Sync asks the tracker if the GUID it installed is now actually being tracked as a deleted item. * If so, just note the fact in the log and return without additional checking. * Next sync should upload a deleted record for that addon. * Profit? Although I guess I'm missing something - there's no "addon-2" in the above scenario :) Edouard, are you saying that tabimprovelite deletes *itself* on install? If so, the above might make sense. If not, it doesn't :)

Sorry I was a bit in a hurry when I typed this comment, here's the correct version: If tabimprovelite is installed and enabled: tabtweak deletes itself If tabimprovelite is installed and disabled: tabimprovelite is deleted