Confusion around new events after skipWaiting

[asakusuma]

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.

[mfalken]

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).

[asakusuma]

@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 skipWaiting, but I think it would be good to also codify a global limit for how long any outgoing worker is allowed to stay alive. In other words, handle both the "skipWaiting" and "all clients closed" scenarios.

Another option would be to start activation immediately in both scenarios. Both the fire functional event and on fetch request algorithm have If activeWorker’s state is activating, wait for activeWorker’s state to become activated. steps. This would mean that for events that are already mid-flight, their handling worker would change from active to redundant mid-flight.

[mfalken]

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.

[asakusuma]

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
See also: #1303 (comment)