Race in Schedule Job algorithm handling of equivalent job promises

[wanderview]

Currently the Schedule Job algorithm says:

If job is equivalent to lastJob, append job’s promise to lastJob’s list of equivalent job promises.

The intention being to combine repeated jobs (like updates) into a single job where possible.

There is a race, however. Some jobs resolve their promises before Finish Job is complete. For example, the Install algorithm calls Resolve Job Promise on step 6, but may call Finish Job much later at step 19. In between these steps the algorithm waits for the install event to be fired and handled.

If Schedule Job runs between when Resolve Job Promise and Finish Job are invoked, then appending the new promise won't have any effect. It will never get resolved.

[wanderview]

I think maybe the easiest solution would be to set a flag when the Resolve Job Promise is run. Then we can simply avoid the coalescing optimization if that flag is set.

[jungkees]

Ah.. right. Thanks for spotting this!

I think there are two options:
(A) as suggested

I think maybe the easiest solution would be to set a flag when the Resolve Job Promise is run. Then we can simply avoid the coalescing optimization if that flag is set.

(B) For the equivalent incoming job, if the lastJob's promise has settled already, settle job's promise accordingly.

(A) seems simpler but then #800 (comment) won't be a solution for .update() failing in oninstall any more (as the job will be queued). (B) doesn't involve the same issue but will have to additionally store the state of the promise settlement values for the lastJob. Which option would be better?

[wanderview]

My initial gut feeling would be to explicitly handle the "update() call during install event" case and do case (a) for aggregation. I'm not sure I like keeping state around just in case someone calls update().

I think case (a) is also closer to what devs might expect. If I see a previous update() promise resolve, and then immediately call update() again, I think I would expect a second update process to run.

[wanderview]

If we do option (a), we could put this check in the "job is equivalent" check. If one job has its promise fufilled, but the other does not, then they are not equivalent.

[jungkees]

Agreed on (a). Re the promise check, let's just add checking if the promise has settled in Schedule Job instead of adding this condition to the definition of "equivalent" jobs. (We don't need to add any additional flag even.)

[jungkees]

#800 (comment) should be addressed again.