fix(update): suppress ordinary Windows updates on extended-stable - #1141
fix(update): suppress ordinary Windows updates on extended-stable#1141RomneyDa wants to merge 7 commits into
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
RomneyDa
added
the
status: 🚢 actively landing
clawsweeper
Bot
added
rating: 🐚 platinum hermit
|
Codex review: needs maintainer review before merge. Reviewed August 24, 2026, 4:26 PM ET / 20:26 UTC. ClawSweeper reviewWhat this changesThe PR defers automatic Windows update checks until Gateway resolution and suppresses the companion updater only when an authenticated Gateway reports the extended-stable channel. Merge readinessKeep open. Current main still runs the ordinary updater without consulting a Gateway update track, but this member-authored branch is dirty against a substantially refactored main and needs an intentional rebase before landing. Priority: P1 Review scores
Verification
Live VerificationCommand: Result: FAIL (failed) — execution before step 1 Assertions:
How this fits togetherThe tray companion connects to an operator Gateway, which owns the selected OpenClaw update track. The tray updater consumes that track before checking the separate Windows release feed and potentially showing an update dialog. flowchart LR
A[Tray startup] --> B[Operator Gateway connection]
B --> C[Authenticated handshake]
C --> D[Gateway update status]
D --> E{Extended-stable?}
E -->|Yes| F[Skip companion update]
E -->|No or unavailable| G[Check Windows release]
G --> H[Update dialog or app launch]
Decision needed
Why: The requested behavior remains absent, but the branch cannot merge and crosses recently refactored tray and Gateway lifecycle seams. Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Rebase the policy onto current main, integrate it through the current Gateway connection lifecycle, and validate extended-stable suppression plus missing, unauthorized, and error fallbacks on the rebased head. Do we have a high-confidence way to reproduce the issue? Yes, source-reproducible: current main calls the ordinary updater directly, while the branch's controlled Gateway proof covers extended-stable and fallback responses. Is this the best way to solve the issue? Yes in principle, but not as this merge result: the policy is narrow and its fallback design is sound, yet it needs a current-main rebase and protocol-contract confirmation. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against ccd64bbb7d68. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (9 earlier review cycles; latest 8 shown)
|
clawsweeper
Bot
added
rating: 🦐 gold shrimp
|
Parallels Release-mode proof on exact head
The screenshot framebuffer was black in this guest, so the UI evidence is native UI Automation plus guest logs rather than attached screenshots. Test metadata, mock settings, and temporary guest build state were cleaned up after the run. |
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
clawsweeper
Bot
added
P1
clawsweeper
Bot
added
rating: 🦞 diamond lobster
clawsweeper
Bot
removed
the
status: ⏳ waiting on author
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
clawsweeper
Bot
added
rating: 🦐 gold shrimp
|
Current-head Parallels Release validation for
The earlier detailed Release proof comment covers the omitted |
|
@clawsweeper re-review |
clawsweeper
Bot
added
proof: sufficient
clawsweeper
Bot
added
rating: 🦐 gold shrimp
1 participant
Related: openclaw/openclaw#118518
What Problem This Solves
Fixes an issue where Windows Companion users on an extended-stable Gateway would be prompted to install the repository's ordinary latest Windows release.
Why This Change Was Made
The Gateway is the authoritative owner of the installed OpenClaw update track. The companion now waits for an authenticated
hello-ok, reads the additiveupdate.status.effectiveChannelfield, and suppresses Updatum only forextended-stable. A missing field, old or unauthorized Gateway, connection failure, and no configured operator Gateway retain the existing standalone updater behavior.The companion PR depends on OpenClaw PR #118518 adding
effectiveChanneltoupdate.status; it remains compatible with older Gateways that omit the field.User Impact
Extended-stable users no longer see ordinary Windows release upgrade prompts. Stable and beta users, and users whose Gateway cannot provide the update track, continue receiving the existing Windows update experience.
Evidence
Production LOC: +159/-15 (net +144). Tests: +123/-1 (net +122). The production growth is the additive typed Gateway contract and the one canonical lifecycle owner for update-track resolution; test growth covers parser policy, real loopback RPC frames, Gateway errors, startup fallback, and handshake ordering.
git diff --checkpassed on this exact head.dotnet, so native build/test commands could not run there (zsh: command not found: dotnet).7f03dffc2278a6a667812d71798a5f9137bd1438: Debug WinUI build, required shared/tray tests, and active UI verification passed. It demonstrated extended-stable suppression and the visible ordinary update dialog fallback for missing/error Gateway status.Change Type
Scope
winnodeValidation
git diff --check(passed)dotnetcommands blocked because the macOS host does not have the .NET SDK.Real Behavior Proof
7f03dffc2278a6a667812d71798a5f9137bd1438update.status.effectiveChannel=extended-stable, then missing/error status responses.Security Impact
update.statusbefore its existing GitHub updater check; unavailable/unauthorized calls fall back without exposing credentials.Compatibility and Migration
Review Conversations