Looking at two random instances, I see: 1. The runtime is only ~70 sec. Given that the [terminator waits 60 + 3 sec](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/terminator/nsTerminator.cpp#59,63) and that there is probably some general overhead, the [updater task apparently resolves its promise](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#243,269) way [before the background task framework times out](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#248) and the background task framework initiates the normal shutdown. 2. The `BitsCommander` thread is stuck somewhere in doing RPC. This probably means, that nothing in the updater task was waiting (long enough) for whatever processing is happening on that thread, but just returned? I did not follow through the code again, but rethinking I would expect that there is some hole in the chain of promises that should ensure to not return from the updater background task while work is happening on the `BitsCommander` thread. Once we fix that hole, we would either: - see successful runs that just were slower than normal, leading to this race with shutdown - see the [background task timeout of 10 minutes](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#42) in our runtime if we are really stuck forever BTW, I do not expect that these cases will decrease now that bug 1832252 or the other improvements from bug 1832089 landed.
Bug 1741675 Comment 28 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Looking at two recent random instances [like this](https://crash-stats.mozilla.org/report/index/4b5cad0b-4be0-411b-9795-7f9920230519#tab-details), I see: 1. The runtime is only ~70 sec. Given that the [terminator waits 60 + 3 sec](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/terminator/nsTerminator.cpp#59,63) and that there is probably some general overhead, the [updater task apparently resolves its promise](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#243,269) way [before the background task framework times out](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#248) and the background task framework initiates the normal shutdown. 2. The `BitsCommander` thread is stuck somewhere in doing RPC. This probably means, that nothing in the updater task was waiting (long enough) for whatever processing is happening on that thread, but just returned? I did not follow through the code again, but rethinking after understanding a bit better how the framework works I would expect that there is some hole in the chain of promises that should ensure to not return from the updater background task while work is happening on the `BitsCommander` thread. Once we fix that hole, we would either: - see successful runs that were just slower than normal, leading to this race with shutdown - see the [background task timeout of 10 minutes](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#42) in our runtime if we are really stuck forever BTW, I do not expect that these cases will decrease now that bug 1832254 or the other improvements from bug 1832089 landed.
Looking at two recent random instances [like this](https://crash-stats.mozilla.org/report/index/4b5cad0b-4be0-411b-9795-7f9920230519#tab-details), I see: 1. The runtime is only ~70 sec. Given that the [terminator waits 60 + 3 sec](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/terminator/nsTerminator.cpp#59,63) and that there is probably some general overhead, the [updater task apparently resolves its promise](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#243,269) way [before the background task framework times out](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#248) and the background task framework initiates the normal shutdown. 2. The `BitsCommander` thread is stuck somewhere in doing RPC. This probably means, that nothing in the updater task was waiting (long enough) for whatever processing is happening on that thread, but just returned? I did not follow through the code again, but rethinking after understanding a bit better how the framework works I would expect that there is some hole in the chain of promises that should ensure to not return from the updater background task while work is happening on the `BitsCommander` thread. Once we fix that hole, we would either: - see successful runs that were just slower than normal, hence avoiding this race with shutdown - see the [background task timeout of 10 minutes](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#42) in our runtime if we are really stuck forever BTW, I do not expect that these cases will decrease now that bug 1832254 or the other improvements from bug 1832089 landed.
Looking at two recent random instances [like this](https://crash-stats.mozilla.org/report/index/4b5cad0b-4be0-411b-9795-7f9920230519#tab-details), I see: 1. The runtime is only ~70 sec. Given that the [terminator waits 60 + 3 sec](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/terminator/nsTerminator.cpp#59,63) and that there is probably some general overhead, the [updater task apparently resolves its promise](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#243,269) way [before the background task framework times out](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#248) and the background task framework initiates the normal shutdown. 2. The `BitsCommander` thread is stuck somewhere in doing RPC. This probably means, that nothing in the updater task was waiting (long enough) for whatever processing is happening on that thread, but that it just returned too early? I did not follow through the code again, but rethinking after understanding a bit better how the framework works I would expect that there is some hole in the chain of promises that should ensure to not return from the updater background task while work is happening on the `BitsCommander` thread. Once we fix that hole, we would either: - see successful runs that were just slower than normal, hence avoiding this race with shutdown - see the [background task timeout of 10 minutes](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#42) in our runtime if we are really stuck forever BTW, I do not expect that these cases will decrease now that bug 1832254 or the other improvements from bug 1832089 landed.
Looking at two recent random instances [like this](https://crash-stats.mozilla.org/report/index/4b5cad0b-4be0-411b-9795-7f9920230519#tab-details), I see: 1. The runtime is only ~70 sec. Given that the [terminator waits 60 + 3 sec](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/terminator/nsTerminator.cpp#59,63) and that there is probably some general overhead, the [updater task apparently resolves its promise](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#243,269) way [before the background task framework times out](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#248) and the background task framework initiates the normal shutdown. 2. The `BitsCommander` thread is stuck somewhere in doing RPC. This probably means, that nothing in the updater task was waiting (long enough) for whatever processing is happening on that thread, but that the task just returned too early? I did not follow through the code again, but rethinking after understanding a bit better how the framework works I would expect that there is some hole in the chain of promises that should ensure to not return from the updater background task while work is happening on the `BitsCommander` thread. Once we fix that hole, we would either: - see successful runs that were just slower than normal, hence avoiding this race with shutdown - see the [background task timeout of 10 minutes](https://searchfox.org/mozilla-central/rev/a1036b237f2c132ac990c715ae8d20f441657113/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#42) in our runtime if we are really stuck forever BTW, I do not expect that these cases will decrease now that bug 1832254 or the other improvements from bug 1832089 landed.