[BUG] Updates page stuck on "No updates" - the engine inside the GUI finds nothing, but the same engine run --headless in the same session finds them

Fermée
  • Quelque chose ne va pas ?
#5,683 2 commentaires 1 réaction 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Une pull request liée a déjà été fusionnée.

  • #5710 par @GabrielDuf — fusionnée

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
csharp
Domaine
backend, desktop

Piste de recherche

Start by comparing the GUI hosted engine with the headless engine around the WinGet ListUpdates task and the single instance path; the report names src/UniGetUI.PackageEngine.Managers.WinGet and WindowsPackageManager.Interop. Reproduce by querying updates through the GUI session, then running the same binary with --headless in the same session. Done means both modes return the same expected updates for this reproduction.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug needs-author-answer priority: high winget
Please confirm these before moving forward
  • I have searched for my issue and have not found a work-in-progress/duplicate/resolved issue.
  • I have tested that this issue has not been fixed in the latest (beta or stable) release.
  • I have checked the FAQ section for solutions.
  • This issue is about a bug (if it is not, please use the correct template).
UniGetUI Version

2026.3.3 (Build 107, Avalonia UI, installed from the setup exe - not the MSIX)

Windows version, edition, and architecture

Windows 11 Pro 25H2, build 26200, x64. winget 1.29.380 (DesktopAppInstaller 1.29.380.0). Single user, admin capable, normally running unelevated.

Describe your issue

The Updates page shows "No updates" permanently. Weird part: it's only the engine instance hosted by the GUI that does this, not the app's engine in general.

Proof from the same box, same user, same Windows session, minutes apart:

  • GUI running: querying that exact session through its IPC (uniget package updates) returns {"updates": []} every time
  • kill the GUI, run UniGetUI.exe --headless from PowerShell, same session: the app's CLI returns 4 updates with isUpgradable true (KillDisk, Battle.net, NS-USBloader, Ubisoft Connect)
  • winget upgrade in that same console agrees with the headless engine (3 upgrades + 2 unknown, which are exactly the Battle.net/NS-USBloader pair)

I went after every suppression path first so this report would be clean: trimmed WinGetAlreadyUpgradedPackages.json and WinGetUpdateAttempts.json (app closed, byte-verified afterwards, no affected ids in there), ignore list empty, no pins on the affected packages, restarted a bunch, ran elevated (same result), fresh boot after clearing a zombie instance. GUI keeps saying 0. Elevated doesn't change it either.

One more thing that matters: winget itself returns different upgrade lists in the console vs over ssh on this machine (same user) - I'm filing that over at microsoft/winget-cli#6140 where it partially fits. But the GUI-empty thing above reproduces fully inside one session, so it's separate from the ssh/session thing.

Steps to reproduce the issue
  1. Open UniGetUI, Updates page shows "No updates". While it's open: uniget package updates -> {"updates": []} (this CLI probe attaches to the GUI's own session registration)
  2. Quit UniGetUI completely. From plain PowerShell, same user:
    UniGetUI.exe --headless --ipc-api-transport tcp --ipc-api-port 7061
  3. uniget --transport tcp --tcp-port 7061 package updates
    -> 4 updates, isUpgradable true
  4. winget upgrade in the same console -> 3 upgrades + 2 unknown, matches the headless engine
  5. Relaunch the GUI, reload Updates -> still 0

Also, from inside one GUI session: package installed returns correct rows (e.g. Audacity 3.7.9) and package search finds the catalog entry (Audacity 4.0.2 available, isUpgradable false). So installed-side and available-side data are both fine in that same session - only the update computation comes back empty.

UniGetUI Log
2026.3.3 keeps app/manager logs in memory per session (no file export), so this is the tail captured live over the IPC API while the GUI session was alive:

App log (GUI session): normal boot - Build 107, UI Framework: Avalonia, .NET 10.0.14, Elevated: False, Packaged (MSIX): False, "Api running on named pipe UniGetUI.IPC". One recurring warning: "Unable to retrieve secret for resource 'UniGetUI/GitHubAccessToken': Element not found" (x2 at boot). Managers load normally afterwards.
Package Managers Logs
winget manager, GUI session (over IPC):
- Logged subprocess task on manager Winget, type RefreshIndexes - winget.exe " source update --disable-interactivity " - start 15:07:38, end 15:07:39 - Return code: SUCCESS (0)
- Logged native task on manager Winget, type ListUpdates - start 15:07:39, end 15:07:47 - "The task reported success"
- OtherTask - native, success

Both scan tasks report SUCCESS, then the update list served by that session stays empty ({"updates": []}, queried repeatedly via its own token). The same binary run --headless in the same session minutes later produces the correct list.

winget.exe upgrade, same console session (ground truth):
Active@ KillDisk 25   LSoftTechnologies.ActiveKillDisk        < 26.0.7   ->  26.0.7   winget
Epic Online Services  EpicGames.EpicOnlineServices            4.2.1      ->  4.3.1    winget
Ubisoft Connect       Ubisoft.Connect                         < 175.0.0.13393 -> 175.0.0.13393  winget
3 upgrades available. 2 package(s) have version numbers that cannot be determined. (those 2 = Battle.net + NS-USBloader, which the headless engine does include)
Relevant information

Possibly related: #4545 (winget CLI reports upgrades but UniGetUI didn't - fixed in 2026.1.7 with the reload refresh fix; I'm on 2026.3.3 and this survives that fix, but the split is different: GUI-hosted engine vs headless engine in the same session). #5541 also shows GUI/headless hosting differences in this layer. Upstream context: microsoft/winget-cli#6140 (winget returns different sets per session type - I'm adding a comment there with same-user data).

My unproven suspicion: the native ListUpdates COM task inside the GUI-hosted process (src/UniGetUI.PackageEngine.Managers.WinGet + WindowsPackageManager.Interop) returns S_OK with zero results once the Avalonia shell has booted, while headless (no UI shell) enumerates fine. Also seen: relaunching while an old instance is mid-exit gets redirected into a zombie that has no working engine or API at all (MainInterface pipe redirect) - maybe worth a look on the single-instance path too.

Happy to test a debug build or pull more captures - the headless/GUI differential is a 60 second repro on my side.

Screenshots and videos

Nothing visual that helps - it's just an empty Updates page with a working engine behind it. Can record the CLI differential live if you want it.

Langage dominant
C#
Étoiles
26.8k
Forks
970
Merge moyen
17 h 26 min
PR mergées (30 j)
134

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de Devolutions/UniGetUI

Toutes les issues de Devolutions/UniGetUI

Issues similaires

Plus d'issues C#

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.