-
Notifications
You must be signed in to change notification settings - Fork 312
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
Confusion around new events after skipWaiting #1295
Comments
Yes I believe the spec intention is to keep sending functional events to the active worker. To deal with the problem of never activating due to continuous events, Chrome implements a hard timeout of 5 minutes to let a "lame duck" worker continue being the active worker. In theory this can also happen without skipWaiting: i.e., all clients are closed but the active worker keeps getting events somehow (e.g., lots of push messages). |
@mattto I assume you meant to say "to prevent a 'lame duck' worker continue being the active worker" If we are going to pick a single approach, I would prefer the #1292 approach to codifying the "lame duck" prevention for Another option would be to start activation immediately in both scenarios. Both the fire functional event and on fetch request algorithm have |
Yea that was phrased unclearly. The lame duck worker is allowed 5 minutes of being the active worker then it gets kicked out. Letting the old worker stay alive to finish inflight requests, but activating immediately and sending new events to the newly active worker also seems like a possible approach. |
At TPAC, we decided this was a bad idea since events queued to the incoming worker could get mega delayed if an in-flight take a while. Closed in favor of #1292 |
Once the Skip Waiting Flag is set, but before the waiting worker becomes active, are incoming fetch and and functional events still sent to the active worker?
I don't see any spec provisions for handling incoming events during the transition that is kicked off by
skipWaiting
. Try Activate doesn't actually activate unless there are no pending events. So it seems like activation after skipWaiting could be delayed by continually fetching before the last fetch completes.The text was updated successfully, but these errors were encountered: