Steps to reproduce:
- Launch Unity Hub 3.22.0-beta.1 and open the "Downloads and activity" drawer
- Start a module download large enough to still be running after a few seconds: "/Applications/Unity Hub.app/Contents/Resources/unity" install-modules -e 6000.6.2f1 -m linux-server -y --accept-eula --no-cm
- After about 5 seconds, while the row still reads state='downloading', end the process that owns the download, either by quitting the Hub from the menu and then ending the CLI process, or with pkill -f "MacOS/Unity Hub"
- Relaunch the Hub and open the "Downloads and activity" drawer
- Hover the drawer entry and look for any control on it
- Wait several minutes with the Hub running and re-read the drawer
- Run "/Applications/Unity Hub.app/Contents/Resources/unity" cache clean -y, relaunch the Hub and look again
Actual results: The drawer permanently shows "Unity 6.6 (6000.6.2f1) Silicon Downloading with the Unity CLI," even though the download process is gone and no bytes are moving. The entry carries no cancel, retry or dismiss control, and the state survives a Hub restart, four minutes of idling, and a cache clean.
Expected results: On start-up, the Hub reconciles download rows whose owning process no longer exists, marking them failed or interrupted and offering retry or dismiss. At minimum, the drawer entry includes a dismiss control so the user isn't left with a permanent false "Downloading" state.
Reproducible with versions: 3.22.0-beta.1
Not reproducible with: No other versions tested
Tested on (OS): MacBook Pro - Tahoe 26.6.2