There is an attempt in Sync to handle a 404 fetching the XPI for an addon and ensure that the addon is *not* retried next time (ie, that the failure to install is ignored in future Syncs.) There is an attempt to encapsulate that in a test at https://dxr.mozilla.org/mozilla-central/rev/c9a70b64f2faa264296f0cc90d68a2ee2bac6ac5/services/sync/tests/unit/test_addons_store.js#419 But in reality, that's not what is being tested - the addon is failing to install because the test hasn't arranged to allow http:// installs - so we don't even try to fetch the XPI, let alone handle the 404 correctly. If we change that test to allow http://, the test fails. It does see the 404, but has no way of determining that - the failure looks like any abstract "network error" - it looks difficult to distinguish a 404 from (say) "connection refused" if there's a transient error - and we do *not* want to treat a transient network error the same as a 404 as we *do* want to retry next sync in that case. Bug 1275139 is changing the tests so http:// installs are allowed. As this causes the test to fail as mentioned above, and given there's no obvious way to change the behaviour so the intent of the test works, that bug is arranging for the error to be ignored. We should work out how to get the intended behaviour WRT 404 responses then re-enable that test. (OTOH though, given the addon must be listed in the AMO repository, I wonder how often in practice we will find a valid addon via AMO metadata but then fail 404 fetching the XPI? So maybe this isn't a problem in practice)
You need to log in before you can comment on or make changes to this bug.