should update() during top level script evaluation be ignored?

[wanderview]

The wpt tests we imported from blink has this code at the top level of one of its service worker scripts:

// update() during the script evaluation should be ignored.
self.registration.update();

I don't see anything in the spec that does this. It seems like it might be a good idea, though, to avoid potential infinite async update loops. For example, if the install event fails or something I think you could end up with an endless set of failing update jobs running in the background.

[wanderview]

@mattto, can you clarify exactly what chrome does in this case? Does it truly ignore it silently or does it reject with an InvalidStateError?

[mfalken]

Let me take a look.

As a process note, I'm having trouble staying on top of Github mail. Is it possible to assign me to these issues that are blocked on my feedback, so I can use the Github's issue tracker to keep track of my tasks?

[mfalken]

Ah, I see searching issues for mentions:matto is a pretty good way.

[mfalken]

Ah you mentioned the wrong matto. I'm @mattto with three t's.

[wanderview]

Ah, sorry! Fixed in the comment above.

[ehsan]

I think it makes more sense to reject the promise. Ignoring it silently seems wrong to me.

[mfalken]

Looks like we reject with a InvalidStateError.

The spec probably needs to be revised? In update(), Get Newest Worker is not necessarily null, if there's an active or waiting worker. Then in 9.2 Update, the installing version would be terminated.

[jungkees]

I don't see any problem with the current text. If the install event fails, the worker will get redundant. Rejecting the promise (update() step 4) when the newest worker is null should be enough I guess.

[jungkees]

Get Newest Worker is not necessarily null, if there's an active or waiting worker.

That's right. And even in the example in the OP, update() was called within the installing worker's script, the newest worker, the installing worker itself, is always there. But the Schedule Job will aggregate this update() job in favor of the running installation, so there won't be such an endless set of failing updates.

[wanderview]

That's right. And even in the example in the OP, update() was called within the installing worker's script, the newest worker, the installing worker itself, is always there. But the Schedule Job will aggregate this update() job in favor of the running installation, so there won't be such an endless set of failing updates.

You will still end up with continuous updates running once every 1 second (or whatever update delay the particular browser uses). This seems bad to me. I think we should remove the potential for infinite loops in job scheduling where possible.

I think it would be better to silently resolve the update() promise with success if called:

1. During top level sw script evaluation.
2. Called while install event is being processed.

In both cases we can argue an update is already in progress and its the same kind of short-circuit as Register does in its step 5.3.

[jakearchibald]

You will still end up with continuous updates running once every 1 second

I'm not following this.

Assuming the browser has an active worker that contains only self.registration.update();

1. SW spins up for whatever reason
2. Update triggered
3. SW fetched, and it's byte different! self.registration.update(); // v2
4. Installing worker spun up
5. Update triggered
6. SW fetched, byte-identical, ignored
7. Installing worker activates

Sure, you're going to get a fetch for your SW pretty frequently, but this isn't much worse than putting fetch('/whatever') at the top of your SW.