DLC: Remove bootstrap catalog

RESOLVED FIXED in Firefox 56

Status

()

Firefox for Android
General
RESOLVED FIXED
4 months ago
4 months ago

People

(Reporter: sebastian, Assigned: sebastian)

Tracking

(Blocks: 1 bug)

unspecified
Firefox 57
All
Android
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox56 fixed, firefox57 fixed)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Assignee)

Description

4 months ago
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

4 months 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

4 months ago
Blocks: 1272226, 1382596

Comment 2

4 months 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

4 months 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+

Comment 5

4 months ago
Pushed by s.kaspari@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/92853fc3f060
(DLC) Remove outdated bootstrap catalog. r=mcomella

Comment 6

4 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/92853fc3f060
Status: ASSIGNED → RESOLVED
Last Resolved: 4 months ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
(Assignee)

Comment 7

4 months 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?
status-firefox56: --- → affected
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+
https://hg.mozilla.org/releases/mozilla-beta/rev/18cde0ee42b5
status-firefox56: affected → fixed
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.