Repository navigation
Keep the launcher quiet while an update finishes - #2088
nortonandreev merged 7 commits into
Conversation
|
No actionable comments were generated in the recent review.
 |
| Layer / File(s) | Summary |
|---|---|
Publish update progress and settle handover src/Capacitor.App/ViewModels/UpdateStep.cs, src/Capacitor.App/ViewModels/UpdateFinishViewModel.cs, src/Capacitor.App/App.axaml.cs, test/Capacitor.App.Tests.Unit/UpdateFinishViewModelTests.cs |
UpdateFinishViewModel publishes finishing state and step detail. App attaches that progress to HomeViewModel and settles the handover when progress ends. The local-server step and daemon step report update activity and status. Tests cover progress details, settlement, and step states. |
Show update progress and hold local starts src/Capacitor.App/ViewModels/HomeViewModel.cs, src/Capacitor.App/ViewModels/LauncherNotices.cs, src/Capacitor.App/Views/LauncherPaneView.axaml, test/Capacitor.App.Tests.Unit/HomeViewModelTests.cs, test/Capacitor.App.Tests.Unit/LauncherNoticesTests.cs |
The launcher shows an update notice with step detail and gives it priority over other notice cards. Local starts are disabled while an update is finishing; remote starts remain unaffected. |
Show update state in the main window src/Capacitor.App/StatusColors.cs, src/Capacitor.App/ViewModels/MainWindowViewModel.cs, test/Capacitor.App.Tests.Unit/MainWindowViewModelTests.cs |
The main window shows “Updating…” with the updating brush while an update is finishing. Expired sign-in retains priority. |
Priority:
Estimated code review effort: 3 (Moderate) | ~25 minutes
Change: Bug fix · Severity of issue fixed: Medium · Unblocks: 1 PR
Sequence Diagram(s)
sequenceDiagram
participant UpdateFinishViewModel
participant App
participant HomeViewModel
participant LauncherNotices
participant LauncherPaneView
UpdateFinishViewModel->>App: Emit finishing state and step detail
App->>HomeViewModel: Attach update progress
HomeViewModel->>LauncherNotices: Track update-finishing state
LauncherNotices->>LauncherPaneView: Select and display update notice
Possibly related issues
- kurrent-io/kcap-cli#2078: The change keeps progress visible after early handover and makes the daemon step wait for local-server upgrade completion.
- kurrent-io/kcap-cli#2082: The change adds the update notice, disables local starts while finishing, and restores normal notice selection after settlement.
Possibly related PRs
- kurrent-io/kcap-cli#2050: Introduces the update finish view model and handover flow extended here.
- kurrent-io/kcap-cli#2079: Continues the update handover flow and is connected to the settlement behavior here.
- kurrent-io/kcap-cli#2089: Uses the update banner and update/connection notice state introduced by this change.
Suggested reviewers: alexeyzimarev, realtonyyoung
Merge Risk: 
5ed94
-
No merge-blocking issue was identified in the update experience.
Security architecture risk: 
5ed94
-
The change coordinates local update progress with launch availability without replacing existing remote-machine ownership checks. No introduced security vulnerability was established. Remaining uncertainty concerns abnormal interruption of progress tracking rather than a demonstrated increase in privileges or cross-machine access.
Retained concerns
No architecture-level concerns identified.Security review details
-
Security Blast Radius
- inferred — The demonstrated change affects local launch affordances, notice priority, and offer timing in the current application. Remote targets remain outside the update hold, and progress values do not select a target, account, permission mode, or sandbox posture.
Trust Boundaries and Controls
- observed — Existing remote execution controls remain separate from UI availability. Remote selection filters by viewer ownership, and launch execution rechecks ownership and connectivity before sending the request and again after attachment uploads. Account and harness checks also remain on the execution path.
Resilience and Maintainability Implications
- observed — Handover and disposal are independently idempotent. Disposal stops subscriptions and patience tracking, then publishes a cleared progress state and completes the stream, limiting stale update-state ownership after normal settlement.
-
Pre-merge checks: 
-
Check name Status Explanation Description Check Check skipped - CodeRabbit’s high-level summary is enabled. Linked Issues check Issue #2082requires one update card while the local update finishes, the active step detail, disabled local Start, and normal notices after settlement.UpdateFinishViewModel.Progressreports the fi…Out of Scope Changes check The changes remain connected to issue #2082. Update-step activity, daemon waiting, finished-step details, settlement handover, and the CLI handoff keep update progress accurate until all steps settle.…Full details: Linked Issues check
-
Explanation
Issue
#2082requires one update card while the local update finishes, the active step detail, disabled local Start, and normal notices after settlement.UpdateFinishViewModel.Progressreports the first pending or running step after early handover.HomeViewModeluses that progress to disable local launches and expose the detail.LauncherNoticesgives the update card priority.MainWindowViewModelreports “Updating…” with the update color. Remote selections bypass the local update hold. The added tests cover local settlement and remote selection.
Full details: Out of Scope Changes check
-
Explanation
The changes remain connected to issue
#2082. Update-step activity, daemon waiting, finished-step details, settlement handover, and the CLI handoff keep update progress accurate until all steps settle. The view-model, view, and automated test changes support the required launcher behavior. No unrelated change is demonstrated.
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
497915b to
c8fe0a9
Compare
Opening kcap before the update window settles keeps its view model following the steps, so the launcher shows one card for the update and holds local launches until every step has settled.
Restarting and reconnecting there are what an update still finishing does, so they read as work in flight rather than attention.
A daemon on the new version restarts before the local server is upgraded and drops off when the server stops, so its step waits for the server rather than showing done and then running again.
c0e3386 to
6745010
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
…tack-2088 # Conflicts: # src/Capacitor.App/ViewModels/UpdateFinishViewModel.cs
|
The Windows job failed only in |
Closes #2082 — AI-4686
Stacked on #2079; review that first.
What & why
"Open kcap" on the update window lets people reach running agents or a failed step before the update finishes, but it dropped them into connection cards, an orange "Restarting…"/"Reconnecting…" in the rail and an enabled Start while the local server and daemon were still coming back. The update window's view model now keeps following the steps after an early hand-over. While steps run and this Mac is selected, the launcher shows one "Finishing the update" card that says what is happening ("Downloading the local server", "Restarting the daemon"), the rail reads "Updating…" in purple, and Start waits. Everything returns once the steps settle; the command-line tool offer waits for that too.
The window itself: every finished step has a subheading ("Installed", "Upgraded", "Running"), and a daemon already on the new version shows "Waiting for the local server" until the server is upgraded, rather than done and then running again when the server stops.
Where to look
A remote machine selection keeps its own notices and launches: the update only changes this Mac.
Verification
macOS 26 VM, 1.4.0-beta.7 with a local server, this branch copied over it, "Open kcap" pressed mid-download:
UpdateFinishViewModelTests(19),HomeViewModelTests(127) andMainWindowViewModelTests(110) pass.Summary by CodeRabbit