Show an error when manual AppInstaller update check cannot fetch the feed

[indierawk2k2]

Problem

When the user clicks Check for updates and the AppInstaller feed cannot be resolved or fetched, the UX can appear to do nothing.

This is easy to hit before the MSIX/AppInstaller feed files are merged to master: the fallback feed URLs currently resolve to raw GitHub master paths such as:

• https://raw.githubusercontent.com/openclaw/openclaw-windows-node/master/installer/appinstaller/openclaw-x64.appinstaller
• https://raw.githubusercontent.com/openclaw/openclaw-windows-node/master/installer/appinstaller/openclaw-arm64.appinstaller

Before PR #468 lands, those URLs can return 404. The update check should surface that failure clearly instead of silently leaving the user unsure whether anything happened.

Expected behavior

If manual update check cannot resolve/fetch/parse the AppInstaller feed, show a user-visible error or status message, for example:

Could not check for updates. The AppInstaller feed is unavailable.

Include enough detail for diagnostics/logs, but avoid overwhelming normal users.

Notes

• This should cover missing feed / HTTP 404 / invalid feed / no registered AppInstaller source cases.
• It should not change the packaging behavior; it is a UX/error-reporting follow-up.
• Discovered during PR MSIX distribution hardening: AppInstaller updates and packaged setup launch #468 MSIX/AppInstaller validation.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed May 27, 2026, 4:37 PM ET / 20:37 UTC.

Summary
Keep this open: current main has Updatum-based manual update feedback, but it does not contain the AppInstaller update-feed path the issue is asking to harden. The remaining work should be coordinated with the open MSIX/AppInstaller distribution work rather than closed as already implemented.

Reproducibility: no. high-confidence current-main reproduction path: the AppInstaller update-feed flow described here is not present on main yet. The requested behavior is clear from the issue and related PR context, but it should be verified against the MSIX/AppInstaller branch or a future implementation PR.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
This should be handled with or after the open MSIX/AppInstaller hardening PR because the target AppInstaller update path is not on current main.

Review details

Best possible solution:

Ship the AppInstaller update path with the same visible manual-check failure semantics current main already has for Updatum, including diagnostics for missing feed, HTTP failure, invalid feed, and missing registered source cases.

Do we have a high-confidence way to reproduce the issue?

No high-confidence current-main reproduction path: the AppInstaller update-feed flow described here is not present on main yet. The requested behavior is clear from the issue and related PR context, but it should be verified against the MSIX/AppInstaller branch or a future implementation PR.

Is this the best way to solve the issue?

Unclear until the AppInstaller implementation is settled. The right direction is to reuse the existing manual-check failure UX pattern, but the exact service boundary and UI surface should be coordinated with the MSIX/AppInstaller work.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The AppInstaller update service and feed URLs are still tied to an open draft MSIX/AppInstaller PR, so a standalone main-branch fix could duplicate or conflict with that branch.

Codex review notes: model gpt-5.5, reasoning high; reviewed against bf21e7b216aa.

Label changes

Label changes:

• add P2: This is a normal user-facing update-check improvement with limited blast radius but real release/distribution UX impact.
• add impact:other: The issue affects update-check feedback and diagnostics, which is maintainer-visible but outside the owned auth, session, crash, data-loss, and message-delivery labels.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal user-facing update-check improvement with limited blast radius but real release/distribution UX impact.
• impact:other: The issue affects update-check feedback and diagnostics, which is maintainer-visible but outside the owned auth, session, crash, data-loss, and message-delivery labels.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore

What I checked:

• Repository policy read: AGENTS.md was read in full; its validation guidance applies to future implementation, but this review is read-only and made no code changes. (AGENTS.md:1, bf21e7b216aa)
• No repository vision file: The checkout has no VISION.md, so vision fit cannot be anchored to repository vision text. (bf21e7b216aa)
• Current main still uses Updatum: The tray app imports Updatum and configures an UpdatumManager for the current update path, so the requested AppInstaller feed flow is not the active mainline implementation. (src/OpenClaw.Tray.WinUI/App.xaml.cs:28, bf21e7b216aa)
• Existing manual update errors are generic Updatum feedback: Current main catches update-check exceptions, stores Status="Failed", and shows the localized failure dialog for manual checks, but this code calls AppUpdater.CheckForUpdatesAsync rather than AppInstaller APIs. (src/OpenClaw.Tray.WinUI/App.xaml.cs:3383, bf21e7b216aa)
• No AppInstaller update service on main: Searching src, tests, and docs found no AppInstallerUpdateService, AddPackageByAppInstallerFileAsync call, appinstaller feed files, or latest.appinstaller references on current main. (bf21e7b216aa)
• Open related implementation work: The provided GitHub context links this issue to the still-open draft MSIX/AppInstaller hardening pull request, whose body says it adds AppInstaller update service support and is not merged.

Likely related people:

• Regis Brid: Added the current manual Check for Updates user feedback and failure dialog handling in the tray app. (role: recent area contributor; confidence: high; commits: f3d3fd2772f3; files: src/OpenClaw.Tray.WinUI/App.xaml.cs, src/OpenClaw.Tray.WinUI/Strings/en-us/Resources.resw, tests/OpenClaw.Tray.Tests/LocalizationValidationTests.cs)
• Scott Hanselman: Merged the current app version and update feedback work and appears repeatedly in MSIX packaging history for this area. (role: merger / adjacent packaging contributor; confidence: medium; commits: 9de3ae02cf41, e4dbd31e76a7, 3fc96748d52e; files: src/OpenClaw.Tray.WinUI/App.xaml.cs, src/OpenClaw.Tray.WinUI/Package.appxmanifest, .github/workflows/ci.yml)
• Mike Harsh: Added and then reverted the temporary MSIX AppInstaller feed endpoint that is directly related to unavailable feed behavior. (role: adjacent AppInstaller feed contributor; confidence: medium; commits: 4a606a6b7a12, 48989ebd813e; files: docs/msix-feed/openclaw-x64.appinstaller)
• Ranjesh: Introduced the current App.xaml.cs update-check code and Updatum project reference in the commit that added the tray app surface. (role: introduced current update path; confidence: medium; commits: 6d8541e57008; files: src/OpenClaw.Tray.WinUI/App.xaml.cs, src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[github-actions]

🤖 This is an automated response from Repo Assist.

Good catch — the silent-failure path here is a real UX gap. A few notes that may help when implementing:

Where the current Updatum flow handles failures (for reference parity):
App.xaml.cs around line 3383 catches AppUpdater.CheckForUpdatesAsync exceptions and stores Status = "Failed", which then shows the localized failure dialog. The AppInstaller path should aim for the same visible result.

Specific failure modes to cover (the issue already lists these, but worth noting which are tricky):

• HTTP 404 / network unreachable: straightforward HttpRequestException catch
• Invalid/unparseable .appinstaller XML: catch XmlException / deserialization error
• No registered AppInstaller source: PackageManager.GetPackageVolumes / AddPackageByAppInstallerFileAsync may throw UnauthorizedAccessException or return a null/empty result
• Feed URL resolves but returns wrong content type: check Content-Type before parsing

Suggested message (matching the existing Updatum tone):

"Could not check for updates — the update feed is unavailable. Check your network connection and try again."
With a details/copy button for the diagnostic message.

This should be straightforward to add once the AppInstaller update path in PR #468 lands. Happy to take a first pass at the error-handling layer if that's useful.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@97143ac59cb3a13ef2a77581f929f06719c7402a