Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a way to know when a strategy is fully finished #2040

Closed
philipwalton opened this issue Apr 23, 2019 · 3 comments
Closed

Provide a way to know when a strategy is fully finished #2040

philipwalton opened this issue Apr 23, 2019 · 3 comments
Assignees

Comments

@philipwalton
Copy link
Member

Library Affected:
workbox-strategies

While exploring a possible solution to #1857 I discovered that our caching strategies do not provide a mechanism for observing when the cache write finishes. Similarly, the StaleWhileRevalidate strategy (which makes both a cache read and a network request) does not provide a way to know when the network request has finished.

In all of these strategies we're using event.waitUntil() to keep the service worker alive until all work is done, but that information isn't exposed to users of the strategies, so there's no way to observe when a strategy is actually "done".

In the case of precaching, this is fairly important, so any solution to #1857 is probably dependent on solving this issue first.

A straight-forward solution (but also a breaking change) would be to return an object in the form of {response, done} rather than just returning a Response. Alternatively, to avoid a breaking change we could add a new property to the object passed to makeRequest() that gets resolved once all waiting is done.

(The first option seem cleaner, so my preference would be to time this with the next major release, since I don't think many people are manually using makeRequest() at the moment)

@philipwalton philipwalton self-assigned this Apr 23, 2019
@jeffposnick
Copy link
Contributor

If this is something that was just done internally and affected the makeRequest() return value, and didn't affect the public handlerCallback interface, the first option sounds fine to me.

@johnrobertcobbold
Copy link

@philipwalton would you also consider adding a way of knowing the outcome of the initial cache read when using StaleWhileRevalidate as explained in #2010 ?

@jeffposnick
Copy link
Contributor

This appears to be a duplicate of #2115; closing this in favor of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants