Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Rethink precaching's activate behavior #1793
As far as I can tell, the best way to deal with this is to ensure that the only things that happen during the
I can think of a couple of ways to move to that model:
One tangential benefit of this approach is that it's not necessary to use IndexedDB to maintain out-of-band metadata keeping track of the active mapping of URLs to revision info, which we have to do in Workbox. Adopting this approach would mean eliminating the dependencies on the IndexedDB runtime code from the
The primary downside of this approach is that developers who expect their precached resources to use specific URLs as their cache keys will end up confused; the cached entry for
To work around this, developers would have to do one of two things, each with drawbacks:
A less radical departure from
In this scenario, the
This approach would not lead to extra data being transferred over the network, since we can use
The major downside of this approach is that we'd risk triggering quota errors by maintaining two full copies of all precached resources during the interval between
(This is actually an existing failure scenario that applies today, and our current approach to avoiding it is just to try not to duplicate anything when we can help it; see #1312 for better ideas.)
A tangential downside is that we would have to continue using IndexedDB inside of
I'm not aware of any, but I'm interested in hearing other ideas.
I'd be OK with adding metadata to the URL as long as users have a way to get access to the modified URL in the event they want to write their own caching logic with resources in the precache cache.
I also think we should support a mode that allows users to opt out of this behavior in the event they're already fingerprinting their assets. In fact, since finger printing assets is a best practice, I'd argue we should optimize the precaching module for users who are doing that, while still supporting users who aren't (with your suggestion of the sw-precache approach).
In fact, part of my hesitation around using the precaching module in the past is feeling like it does a bunch of stuff I don't need it to do (e.g. the temp cache), so if we could remove the temp cache and the URL modification for users who are following our caching best practices, that would be my preference.
This was done in
Of course, precaching HTML, if possible, is a good practice, and URLs for HTML documents won't contain in-band versioning hashes. So most developers would end up with a synthetic query parameter appended to the real URL as the cache key for HTML resources.
Ahh, right (not doing this myself I sometimes forget). So in that case my not-yet-formed ideas of how we could separate the logic entirely (so those using fingerprinting don't need to include it) is probably not worth exploring.
This was referenced
Dec 19, 2018
referenced this issue
Jan 8, 2019
From my understanding, here is the chain of events that follow. For simplification, I'll assume that our app uses only two files: main.js and main.css.
If a first installation attempt fails half way through (let's say main.js is successfully downloaded and main.css isn't), the IndexedDB entries (precacheDetailsModel) will be updated to reflect that (so main.js's revision will be updated in the db) and main.js will be added to the temp AppCache. Main.css won't trigger any changes in either AppCache or the indexedDB entries.
When the app is reloaded, everything still works, as all requests are served from the AppCache which was kept intact so far. However, this will automatically trigger a second installation attempt in which:
Given the number of reports we would get of users sending screenshots of bricked CSS apps and the time sensitivity of the issue, we simply forked workbox and applied this fix, which is to basically only update indexedDB if all network requests succeed:
(I think it is one of the possibilities you mentioned above or in #1316). It seems like a proper fix assuming nothing else could go wrong after indexedDB is updated. I suspect this may not be the case: If that's true then this fix makes workbox work in more scenarios, but doesn't provide a 100% guarantee that it will always properly install updates.
Given that we want ultimately use a non-forked version of workbox, we'd be happy to assist with developing PRs that help address this issue in a way that makes sense from your point of view. One possibility I thought of was to write entries to the IndexedDB (precacheDetailsModel), during the install phase, with an additional boolean flag that says they were not yet "activated" (a successful activation would then reset this flag). Any further installation attempt would then ignore any entries that have this flag set. The risk here is that if the activation phase doesn't correctly reset these flags, further updates will download a lot more than needed.
Let me know if there is any way we can help!