422562 - Corrupt/bad downloads on AMO

Status: RESOLVED DUPLICATE of bug 424339

(addons.mozilla.org Graveyard :: Administration, defect)

Description

[Alex Polvi]

It seems like there have been a lot more add-ons that are experiencing bad downloads. 

17:08 < eviljeff|away> is it just me or are there more ppl complaining about bad downloads recently on amo.  I've deleted about 5 out of the review queue.

This is a tracking bug for figuring out why the increase in failed attempts at downloading.

Anyone have ideas?

Comment 1

[Fred Wenzel [:wenzel]]

Don't get me wrong but the first question I recently ask when this happens is "do you have the video downloadmanager add-on installed"? Its user base is surprisingly large, so the bug had a huge impact.

I am not sure how often Firefox auto-updates add-ons, but if they haven't updated since bug 420278 was fixed 10 days ago, it's not surprising they are having download problems. In particular if they don't use their browser frequently and thus haven't given it a chance to update yet?

If this is not the reason, we should try to get feedback on what error is shown, so that it is easier for us to debug.

Comment 2

[Fred Wenzel [:wenzel]]

Ah -- can we blocklist Video Downloadhelper (I messed up the name in comment 1) version 3.1?

Comment 3

[Alex Polvi]

I think there is a different issue at play. For instance, I just pushed the Spectator extension live, but since it is caught by AMO cache, it still appears to be sandboxed. However, updates are still available because whatever the add-on update service does see there is an update... but it appears that it still reports the file hash incorrectly (see bug 422989). 

My theory is that this is caused by an indifference in the cache/live somewhere. Can we:

1) tune down the cache a bit? this might help with this issue -- along with make pushing stuff live take less time (currently it takes 2hours from approval to public).
2) guarantee that everything is cached identically? meaning all queries that involve file version and hash info are the same? or ... I guess this could also be solved by expiring caches when things are modified. 

Comment 4

[Alex Polvi]

Right now I'm trying to install spectator and it is erroring that it cannot find the file because addons.m.o is redirecting to release.m.o and the mirror does not have the file.

The file is on ftp.mozilla.org -- so this is just a propagation issue with one of the mirrors. This should be safe guarded against.

The quick fix, which I propose we implement now, is to limit memcache to only 60s like it was before the API.

Comment 5

[Basil Hashem [:baz]]

Morgamic, can you please verify that the memcache setting is different for AMO pages versus API. 

Comment 6

[Alex Polvi]

Another solution would be to expire any cache related to an add-on when add-ons are modified. This is probably the correct solution.

Tuning the cache down will cause the breakage to happen for less time -- not solve it entirely.

Comment 7

[Wil Clouser [:clouserw]]

(In reply to comment #6)
> Another solution would be to expire any cache related to an add-on when add-ons
> are modified. This is probably the correct solution.

This is not an easy or quick change, fyi.

Comment 8

[Basil Hashem [:baz]]

As someone who experienced this first hand today as I was helping PicLens, I can vouch for the fact that even a 1-hour delay it getting an add-on replaced is not very acceptable.

Comment 9

[Przemyslaw Bialik]

Currently there is a problem with updating Lightning 0.8 to 0.9 because: Download error -228
http://releases.mozilla.org/pub/mozilla.org/addons/2313/lightning-0.9-tb-win.xpi

It can be downloaded directly from AMO
https://addons.mozilla.org/en-US/thunderbird/downloads/file/38055/lightning-0.9-tb-win.xpi
but it can't be updated using updates available system because I conclude it's not yet on the mirrors and releases.mozilla.org are used in this case.

If this is the case can the publishing of addons or update discovery (if possible) for them be delayed until all mirrors are in sync ?
(bad UX)