Draft: fix(install): keep a stalled download from blocking the install queue
Description
Installs were stuck at 0% for every app (common apps and open source), until App Lounge was restarted or the system killed the worker (around 30 min).
The queue only advances when nothing else is running, and it was looking at the AppInstall rows to know that. So a row left in DOWNLOADING or INSTALLING by a worker the system killed still counted as an active install, and no queued app was ever triggered again. Those rows were only reconciled once per process in init(), so within the same process the queue stayed blocked.
The download wait had no timeout either, so a wedged download could keep the worker alive and hold the queue that way too.
So InstallOrchestrator now reconciles the stale rows whenever nothing is actually running, and InstallationProcessor gets a watchdog on the byte counter (10 min without a new byte). The acceptance tests are written in Gherkin in features/ in a separate commit.
Issue
https://gitlab.e.foundation/e/os/backlog/-/work_items/4537
What I tested
- Unit tests only, on the JVM.
InstallQueueStallRegressionTestandInstallationProcessorStallTestwere both failing before the fix. init_doesNotTriggerAwaitingWhenThereIsAnActiveDownloadwas actually asserting the bug (aDOWNLOADINGrow alone blocking the queue) so I updated it to require real work. The legitimate case is still covered by the test just below it.
What I did NOT test
- Nothing on a device. I can't reproduce the issue on demand, so it probably needs someone hitting it again to confirm.
- The 10 min threshold is quite arbitrary to me. If it is too low we kill legitimate slow downloads on a bad connection.
- I still can't explain why clearing storage and cache didn't help in the issue, since it should reset both the Room DB and the WorkManager DB. There is probably something else on top, maybe on the system DownloadManager side.
Risk if this is wrong
- buggy behaviour
- cosmetic
- feature unusable
- data loss, account, or security