Closed
Bug 1386305
Opened 7 years ago
Closed 7 years ago
DLC: Remove bootstrap catalog
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(firefox56 fixed, firefox57 fixed)
RESOLVED
FIXED
Firefox 57
People
(Reporter: sebastian, Assigned: sebastian)
References
Details
Attachments
(1 file)
59 bytes,
text/x-review-board-request
|
mcomella
:
review+
lizzard
:
approval-mozilla-beta+
|
Details |
Initially we shipped a static DLC catalog in the app. This allowed us to immediately download without synchronizing the catalog first. And more importantly: We could ship DLC without waiting for Kinto to be available in production. Now because of bug 1382596 we see a bunch of clients in the wild with an invalid catalog causing a bunch of 404 request on CDN side. I think it's time to retire this bootstrap catalog - it is hard (or impossible) to pull a catalog that we shipped in the app. We have Kinto in production for some time now and we see that the sync of it is working.
Assignee | ||
Comment 1•7 years ago
|
||
Jason: Even with removing this bootstrap catalog we will see some clients hit those URLs for a long time. I guess somehow re-activating those URLs is not really feasible?
Flags: needinfo?(jthomas)
Assignee | ||
Updated•7 years ago
|
Blocks: fennec-dlc
Comment 2•7 years ago
|
||
(In reply to Sebastian Kaspari (:sebastian) from comment #1) > Jason: Even with removing this bootstrap catalog we will see some clients > hit those URLs for a long time. I guess somehow re-activating those URLs is > not really feasible? Kinto records for fennec objects provides two hashes one for the gzipped content and another for the original content. Does fennec client use both of these hashes to validate the object? If fennec client doesn't validate the gzipped object hash then I think it would be straight forward to create new objects and put them in S3. If fennec client uses both hashes it would be more complicated. One of the issues is that gzip metadata will alter the hash of the gzipped object, specifically I think mtime of the original object is the culprit. Assuming that is the only issue we could try to manipulate the mtime during gzip object creation but it would be essentially be a brute force operation.
Flags: needinfo?(jthomas)
Comment hidden (mozreview-request) |
Comment 4•7 years ago
|
||
mozreview-review |
Comment on attachment 8892967 [details] Bug 1386305 - (DLC) Remove outdated bootstrap catalog. https://reviewboard.mozilla.org/r/163974/#review169512 I'm not too familiar with this code but this seems reasonable to me. (note: your try failure is a presumably unrelated failure in testDSAGeneration (or whatever)).
Attachment #8892967 -
Flags: review?(michael.l.comella) → review+
Pushed by s.kaspari@gmail.com: https://hg.mozilla.org/integration/autoland/rev/92853fc3f060 (DLC) Remove outdated bootstrap catalog. r=mcomella
Comment 6•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/92853fc3f060
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox57:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
Assignee | ||
Comment 7•7 years ago
|
||
Comment on attachment 8892967 [details] Bug 1386305 - (DLC) Remove outdated bootstrap catalog. Approval Request Comment [Feature/Bug causing the regression]: We ship a catalog of downloadable content (fonts) inside the app. This catalog is outdated. As we are synchronizing this data from a Kinto server this static catalog isn't needed anymore. [User impact if declined]: The clients are trying to download from a URL that only returns 404 errors. The clients will fix themselves after they updated the local catalog. However the 404 errors are showing up in our CDN monitoring an make it hard to look out for actual problems. [Is this code covered by automated tests?]: It's covered by a unit test and this patch modifies one of those tests accordingly. [Has the fix been verified in Nightly?]: I tested this patch with a local build. The catalog synchronizes nicely from Kinto (as it already does in all release channels) and then starts to download from the correct URLs. [Needs manual test from QE? If yes, steps to reproduce]: - [List of other uplifts needed for the feature/fix]: - [Is the change risky?]: Very Low [Why is the change risky/not risky?]: Instead of shipping a list of things to download we are starting with an empty catalog. [String changes made/needed]: -
Attachment #8892967 -
Flags: approval-mozilla-beta?
Updated•7 years ago
|
status-firefox56:
--- → affected
Comment 8•7 years ago
|
||
Comment on attachment 8892967 [details] Bug 1386305 - (DLC) Remove outdated bootstrap catalog. Sounds like this is not considered risky. Let's try it for beta 1.
Attachment #8892967 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 9•7 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/18cde0ee42b5
Flags: in-testsuite+
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•