1879650 - Background Update Task gets stuck in a loop of connecting to the download and then not completing it

Status: RESOLVED DUPLICATE of bug 1875502

(Toolkit :: Application Update, defect, P3)

Description

[Robin Steuber (she/her) [:bytesized]]

Attachment: backgroundupdate.moz_log

While investigating a different issue (Bug 1856462), I tried manually running background update locally to get some reference logs to compare against those provided by the user. But, to my surprise, my Background Update Task seemed to get stuck in a loop rather than installing the update. To keep things consistent and prevent race conditions, the Background Update Task will not both download and stage the update in the same run, even if the download completes effectively instantly. This is gated by this variable. In theory, this makes it so that if we enter the update cycle at the "checking for update" phase, we won't proceed past the "download" phase.

However, here is what I think is happening instead. _postUpdateProcessing finds the in-progress download and calls downloadUpdate, which will transition the update state to STATE_DOWNLOADING. However, it does this state change at the end of the function, and the function is asynchronous. I believe that this leaves an open opportunity (which seems to be hit pretty consistently, from what I'm seeing) for the Background Update Task to create an AppUpdater instance and inspect its status before the state transition happens, causing it to report STATUS.CHECKING. This sets UpdateService.onlyDownloadUpdatesThisSession = true and leads to the Background Update Task getting stuck in a loop.

Comment 1

[Nick Rishel [:nrishel]]

Setting P3/S3 but I'm assuming :bytesized might want to adjust. It doesn't sound like this is e.g. something that eats system resources or hard blocks updates for extended periods of time?

Comment 2

[Robin Steuber (she/her) [:bytesized]]

I believe that this was fixed by Bug 1875502. As described in comment 0, the race condition was possible because we would try to examine the update state while post update processing was still running. But as of Bug 1875502, we explicitly wait for the update system to initialize before we begin. The initialization includes post update processing, so this should effectively prevent the race condition.