[Task][RFC]: Complete the Desktop execution frontend journeys #5204

Activity

1. huangruiteng

   added

   direction/architecture-evolutionArchitecture evolution and research-incubator work.Architecture evolution and research-incubator work.

   on Sep 27, 2026
2. Duang777 commented on Oct 4, 2026

   

   Duang777

   on Oct 4, 2026

   Collaborator

   More actions

   @huangruiteng I'd like to claim a narrow, currently unowned acceptance gap under this task: stale desktop_update_status responses can overwrite a newer update phase in both apps/desktop/loopx-control-plane/static/boot.js and apps/presentation/dashboard/src/features/personal-workspace/desktop-update.tsx. On current main (ba443e2b), maintenance.rs snapshots update state before the bounded environment probe, while boot.js polls every second without an in-flight or generation guard and desktop-update.tsx commits initial and polling responses unconditionally. A response that captured available before Apply can therefore arrive after the action has moved to downloading, installing_*, or restart_required, expose Apply again, and turn a second click into update_busy or restart_required error UI. This is source-level evidence only; I have not reproduced it in a packaged build yet.

   If this scope is acceptable, I'll move status snapshotting after diagnostics collection, add monotonic request and action fencing to both frontend entry points, and add delayed-response regression coverage proving stale pre-action state cannot replace installing_* or restart_required, Apply stays unavailable after the action begins, and only one Apply request is issued. I'll preserve channel, rollback, and readiness state. #5582 overlaps maintenance.rs, boot.js, and examples/desktop-update-browser-smoke.mjs, so I'll wait for or rebase onto its stabilized revision and avoid changing its runtime-selection behavior.
3. JasonBuildAI commented on Oct 19, 2026

   

   JasonBuildAI

   on Oct 19, 2026

   Contributor

   More actions

   Claim proposal: Windows desktop update and repair parity (the unowned gap behind #5204's per-OS evidence requirement)

   This corresponds to #5204 accepted items 2/3: restart/update/rollback require independent evidence on each operating system. Windows currently has none, and the gap is product-level rather than an implementation detail — on main, Windows only supports "manual updates + a separately installed CLI", while in-app signed updates / rollback / repair exist only on macOS.

   Current evidence (origin/main)

   • apps/desktop/loopx-control-plane/README.md: "Windows preview retains manual CLI installation" and "separately managed CLI selection are unchanged".
   • Root README.md: "Windows preview installers currently use manual updates and a separately installed CLI."
   • docs/product/release-readiness.md: v1.4.1 "Windows artifacts were verified without native client execution"; v1.4.0 "Windows execution … remain unqualified."
   • .github/workflows/desktop-updater.yml: the updater build matrix only contains macos-15; scripts/desktop_update_feed.py publishes only darwin-aarch64; uploads are only .gz/.sig.
   • Rust: the App's signed-update apply/rollback paths (macos_update.rs, update_backup.rs) are macOS-scoped; on Windows the update surface currently resolves to update_platform_unavailable (the feed has no Windows targets).

   Proposed delivery (a detailed one-page proposal is available on request, or can be tracked in a separate issue)

   1. Contract: source/signature (reuse the existing minisign public key), NSIS passive-install and restart semantics, rollback and interruption-recovery boundaries (aligned with the macOS verified backup).
   2. Pipeline: add Windows signed update artifacts to desktop-updater.yml; add windows-x86_64 to the feed (fail-closed when artifacts are incomplete).
   3. Rust/panel: implement Windows recovery/rollback, or first ship an explicit unavailable state.
   4. Docs + release-readiness entries + real-machine acceptance receipts.

   Local dry-run results (Windows 11 x64 · @tauri-apps/cli 2.11.4 · main@dda6f7ef7)

   • Artifact shapes pinned down: NSIS produces LoopX_<version>_x64-setup.exe + *.setup.exe.sig (no .nsis.zip); MSI produces *.msi + *.msi.sig (no .msi.zip). Both .sig files verify offline against the public key, and a one-byte tamper is rejected (the same minisign verification stack used at runtime).
   • Passive install and restart measured: running the installer with the plugin's real arguments /P /UPDATE /R /ARGS completes unattended; a 0.0.1 → 0.0.2 overwrite install updates the registry version and the app automatically restarts into the new version; silent uninstall removes app files and registry entries (one self-delete uninstall.exe remnant was observed and noted).
   • Toolchain consistency: a fresh build correctly embeds the NSIS bundle marker (recognized by the plugin); the bundler's variable-not-found warning when re-bundling a binary that was not re-linked is a local incremental-reuse artifact, not a CI blocker.
   • S2 surface to cover: add a Windows platform entry in desktop_update_feed.py; expand desktop-updater.yml upload globs from .gz/.sig to Windows artifacts; MSI versions must be numeric X.Y.Z (NSIS accepts pre-release identifiers); the CI signing key must match plugins.updater.pubkey (the bundler verifies this explicitly).

   Direction questions (release/security)

   1. Do you accept this gap being claimed, and should the release-pipeline and signing decisions be tracked as a separate issue?
   2. Should the first phase introduce Authenticode signing? (Recommendation: not initially — consistent with today's state, minisign only; evaluate separately later.)
   3. MSI users: is "manual update + guidance" acceptable for the first phase, or must MSI be included in automatic updates?
   4. Rollout gate: main channel first + real-machine install / upgrade / interruption / rollback receipts, then a separate stable approval?
   5. Is this slice order acceptable: S2 (pipeline + feed, main only) → S3 (Rust/panel recovery) → S4 (docs + acceptance)?

   Validation plan: on a real Windows machine, run install → upgrade → interruption recovery → rollback/repair, keeping public-safe receipts for the whole chain.

   Boundary: no PR, no workflow change, and no release-channel change before direction agreement; during implementation, coordinate with the in-flight #6835 (maintenance.rs) to avoid conflicts.