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

fix(service-worker): allow checking for updates when constantly polling the server #40234

Closed
wants to merge 6 commits into from

Conversation

gkalpak
Copy link
Member

@gkalpak gkalpak commented Dec 22, 2020

Previously, the SW would wait to become idle before executing scheduled tasks (including checks for newer app versions). It was considered idle when it hadn't received any request for at least 5 seconds. As a result, if the app performed polling (i.e. sent requests to the server) in a shorter than 5 seconds interval, the SW would never detect and update to a newer app version.
Related issue: #40207

This PR fixes this by adding a max delay to IdleScheduler to ensure that no scheduled task will remain pending for longer than the specified max delay.

This PR also includes some minor refactorings/improvements. See the individual commits for more details.

@gkalpak gkalpak added type: bug/fix action: merge The PR is ready for merge by the caretaker target: patch This PR is targeted for the next patch release area: service-worker Issues related to the @angular/service-worker package labels Dec 22, 2020
@ngbot ngbot bot modified the milestone: Backlog Dec 22, 2020
@google-cla google-cla bot added the cla: yes label Dec 22, 2020
@mary-poppins
Copy link

You can preview 6812895 at https://pr40234-6812895.ngbuilds.io/.

@mary-poppins
Copy link

You can preview 5954d49 at https://pr40234-5954d49.ngbuilds.io/.

@gkalpak gkalpak marked this pull request as ready for review December 22, 2020 17:22
Copy link
Contributor

@sonukapoor sonukapoor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

Copy link
Contributor

@IgorMinar IgorMinar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

cacheNames
// The Chrome debugger is not able to render the syntax properly when the
// code contains backticks. This is a known issue in Chrome and they have an
// open [issue](https://bugs.chromium.org/p/chromium/issues/detail?id=659515) for that.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this issue is now marked as fixed

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! I removed the work-around 🎉

…out unrecoverable state

Previously, the `Driver#notifyClientsAboutUnrecoverableState()` method
would not wait for the completion of the promises created to notify the
clients. Theoretically, this could result in the SW instance's getting
destroyed by the browser before all clients have been notified. This is
extremely unlikely to happen in practice, since the async operations are
very quick, but it _is_ theoretically possible.

This commit ensures that the SW instance will remain alive while
notifying the clients by making `notifyClientsAboutUnrecoverableState()`
await the notification promises.
Previously, clients were notified about updates sequentially. This
wasn't necessary.

This commit changes the `Driver#notifyClientsAboutUpdate()` method to
notify the clients in parallel (by switching from `Array#reduce()` to
`Array#map()` and `Promise.all()`).

This also aligns the `notifyClientsAboutUpdate()` method with the
`notifyClientsAboutUnrecoverableState()` method.
…river#deleteAllCaches()`

This commit refactors `Driver#deleteAllCaches()` to use `Array#map()`
instead of `Array#reduce()` for running async operations in parallel.
This allows avoiding having to recursively wrap Promises with
`Promise.all()`.
This commit refactors the `Driver#handleFetch()` method to not have to
call `event.waitUntil(this.idle.trigger())` in multiple places.
…ng the server

Previously, the SW would wait to become idle before executing scheduled
tasks (including checks for newer app versions). It was considered idle
when it hadn't received any request for at least 5 seconds. As a result,
if the app performed polling (i.e. sent requests to the server) in a
shorter than 5 seconds interval, the SW would never detect and update to
a newer app version.
Related issue: angular#40207

This commit fixes this by adding a max delay to `IdleScheduler` to
ensure that no scheduled task will remain pending for longer than the
specified max delay.
…ting bug

Chrome debugger code highlighting bug [659515][1] has been fixed, so we
can remove the work-around.
(See angular#38332 for more details on the work-around.)

[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=659515
@gkalpak gkalpak removed the request for review from alxhub January 8, 2021 12:10
@mary-poppins
Copy link

You can preview eaa7cf2 at https://pr40234-eaa7cf2.ngbuilds.io/.

@atscott atscott closed this in ad3329a Jan 11, 2021
atscott pushed a commit that referenced this pull request Jan 11, 2021
…40234)

Previously, clients were notified about updates sequentially. This
wasn't necessary.

This commit changes the `Driver#notifyClientsAboutUpdate()` method to
notify the clients in parallel (by switching from `Array#reduce()` to
`Array#map()` and `Promise.all()`).

This also aligns the `notifyClientsAboutUpdate()` method with the
`notifyClientsAboutUnrecoverableState()` method.

PR Close #40234
atscott pushed a commit that referenced this pull request Jan 11, 2021
…river#deleteAllCaches()` (#40234)

This commit refactors `Driver#deleteAllCaches()` to use `Array#map()`
instead of `Array#reduce()` for running async operations in parallel.
This allows avoiding having to recursively wrap Promises with
`Promise.all()`.

PR Close #40234
atscott pushed a commit that referenced this pull request Jan 11, 2021
)

This commit refactors the `Driver#handleFetch()` method to not have to
call `event.waitUntil(this.idle.trigger())` in multiple places.

PR Close #40234
atscott pushed a commit that referenced this pull request Jan 11, 2021
…ng the server (#40234)

Previously, the SW would wait to become idle before executing scheduled
tasks (including checks for newer app versions). It was considered idle
when it hadn't received any request for at least 5 seconds. As a result,
if the app performed polling (i.e. sent requests to the server) in a
shorter than 5 seconds interval, the SW would never detect and update to
a newer app version.
Related issue: #40207

This commit fixes this by adding a max delay to `IdleScheduler` to
ensure that no scheduled task will remain pending for longer than the
specified max delay.

PR Close #40234
atscott pushed a commit that referenced this pull request Jan 11, 2021
…ting bug (#40234)

Chrome debugger code highlighting bug [659515][1] has been fixed, so we
can remove the work-around.
(See #38332 for more details on the work-around.)

[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=659515

PR Close #40234
atscott pushed a commit that referenced this pull request Jan 11, 2021
…out unrecoverable state (#40234)

Previously, the `Driver#notifyClientsAboutUnrecoverableState()` method
would not wait for the completion of the promises created to notify the
clients. Theoretically, this could result in the SW instance's getting
destroyed by the browser before all clients have been notified. This is
extremely unlikely to happen in practice, since the async operations are
very quick, but it _is_ theoretically possible.

This commit ensures that the SW instance will remain alive while
notifying the clients by making `notifyClientsAboutUnrecoverableState()`
await the notification promises.

PR Close #40234
atscott pushed a commit that referenced this pull request Jan 11, 2021
…40234)

Previously, clients were notified about updates sequentially. This
wasn't necessary.

This commit changes the `Driver#notifyClientsAboutUpdate()` method to
notify the clients in parallel (by switching from `Array#reduce()` to
`Array#map()` and `Promise.all()`).

This also aligns the `notifyClientsAboutUpdate()` method with the
`notifyClientsAboutUnrecoverableState()` method.

PR Close #40234
atscott pushed a commit that referenced this pull request Jan 11, 2021
…river#deleteAllCaches()` (#40234)

This commit refactors `Driver#deleteAllCaches()` to use `Array#map()`
instead of `Array#reduce()` for running async operations in parallel.
This allows avoiding having to recursively wrap Promises with
`Promise.all()`.

PR Close #40234
atscott pushed a commit that referenced this pull request Jan 11, 2021
)

This commit refactors the `Driver#handleFetch()` method to not have to
call `event.waitUntil(this.idle.trigger())` in multiple places.

PR Close #40234
atscott pushed a commit that referenced this pull request Jan 11, 2021
…ng the server (#40234)

Previously, the SW would wait to become idle before executing scheduled
tasks (including checks for newer app versions). It was considered idle
when it hadn't received any request for at least 5 seconds. As a result,
if the app performed polling (i.e. sent requests to the server) in a
shorter than 5 seconds interval, the SW would never detect and update to
a newer app version.
Related issue: #40207

This commit fixes this by adding a max delay to `IdleScheduler` to
ensure that no scheduled task will remain pending for longer than the
specified max delay.

PR Close #40234
atscott pushed a commit that referenced this pull request Jan 11, 2021
…ting bug (#40234)

Chrome debugger code highlighting bug [659515][1] has been fixed, so we
can remove the work-around.
(See #38332 for more details on the work-around.)

[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=659515

PR Close #40234
@gkalpak gkalpak deleted the fix-sw-idle-delay branch January 11, 2021 18:52
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Feb 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker area: service-worker Issues related to the @angular/service-worker package cla: yes target: patch This PR is targeted for the next patch release type: bug/fix
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants