Bugzilla

Interestingly we made a quite good job in [avoiding AsyncShutdownTimeout for background tasks](https://crash-stats.mozilla.org/search/?async_shutdown_timeout=%21__null__&background_task_name=%21__null__&product=Firefox&date=%3E%3D2023-04-09T07%3A23%3A00.000Z&date=%3C2023-05-09T07%3A23%3A00.000Z&_facets=signature&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature), see for example bug 1820517, bug 1814104, bug 1799421. The remaining hangs are probably "things that start and were never even designed to interact with shutdown" such that the terminator catches them.

I think we have several paths here (and might want all):

1. Mitigate the impact by having an (arbitrary) timeout at the end of the background task before starting  the shutdown sequence of the process. This is an easy hack but obviously not really nice. And we should check the `Shutdown Reason` annotation if we see many cases of OS shutdown (my gut feeling is: no, but it is not yet aggregatable, so we should take a closer look) - delaying process end could delay OS shutdown. But I assume the `backgroundupdate` is something we run anytime during normal operations, IIUC.
2. Redesign how startup actually works, making sure that we have async shutdown blockers for every piece that starts up.
3. Have a closer look at what things are actually needed to startup for a background task. My current assumption is that many things are not needed at all, but there might be hidden dependencies hard to solve. Especially on Windows I'd check if we start GPU processes or similar, or accessibility features or other heavy COM objcects.

Given that 2. and 3. are desirable but hard, I'd start from 1.

Interestingly we made a quite good job in [avoiding AsyncShutdownTimeout for background tasks](https://crash-stats.mozilla.org/search/?async_shutdown_timeout=%21__null__&background_task_name=%21__null__&product=Firefox&date=%3E%3D2023-04-09T07%3A23%3A00.000Z&date=%3C2023-05-09T07%3A23%3A00.000Z&_facets=signature&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature), see for example bug 1820517, bug 1814104, bug 1799421. The remaining hangs are probably "things that start and were never even designed to interact with shutdown" such that the terminator catches them.

I think we have several paths here (and might want all):

1. Mitigate the impact by having an (arbitrary) timeout at the end of the background task before starting  the shutdown sequence of the process. This is an easy hack but obviously not really nice. And we should check the `Shutdown Reason` annotation if we see many cases of OS shutdown (my gut feeling is: no, but it is not yet aggregatable, so we should take a closer look) - delaying process end could delay OS shutdown. But I assume the `backgroundupdate` is something we run anytime during normal operations, IIUC.
2. Redesign how startup actually works, making sure that we have async shutdown blockers for every piece that starts up.
3. Have a closer look at what things are actually needed to startup for a background task. My current assumption is that many things are not needed at all, but there might be hidden dependencies hard to solve. Especially on Windows I'd check if we start GPU processes or similar, or accessibility features or other heavy COM objcects. (Disclaimer: I have no idea if any of these examples really happens.)

Given that 2. and 3. are desirable but hard, I'd start from 1.

Interestingly we made a quite good job in [avoiding AsyncShutdownTimeout for background tasks](https://crash-stats.mozilla.org/search/?async_shutdown_timeout=%21__null__&background_task_name=%21__null__&product=Firefox&date=%3E%3D2023-04-09T07%3A23%3A00.000Z&date=%3C2023-05-09T07%3A23%3A00.000Z&_facets=signature&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature), see for example bug 1820517, bug 1814104, bug 1799421. The remaining hangs are probably "things that start and were never even designed to interact with shutdown" such that the terminator catches them.

I think we have several paths here (and might want all):

1. Mitigate the impact by having an (arbitrary) timeout at the end of the background task before starting  the shutdown sequence of the process. This is an easy hack but obviously not really nice. And we should check the `Shutdown Reason` annotation if we see many cases of OS shutdown (my gut feeling is: no, but it is not yet aggregatable, so we should take a closer look) - delaying process end could delay OS shutdown. But I assume the `backgroundupdate` is something we run anytime during normal operations, IIUC.
2. Redesign how startup actually works, making sure that we have async shutdown blockers for every piece that starts up.
3. Have a closer look at what things are actually needed to startup for a background task. My current assumption is that many things are not needed at all, but there might be hidden dependencies hard to solve. Especially on Windows I'd check if we start GPU processes or similar, or accessibility features or other heavy COM objcects. (Disclaimer: I have no idea if any of these examples really happens.)

Given that 2. and 3. are desirable but hard, I'd start from 1.

Edit regarding 1.: I assume [here in `runBackgroundTaskNamed`](https://searchfox.org/mozilla-central/rev/373d05f4eabdb90a6480d5d36d983b8bff36c9d8/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#237-239) could be a good place to add a waiting promise.