Repository navigation
fix(proxy): report updater activation state truthfully - #1264
Conversation
|
Warning Review limit reached
Next review available in: 59 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThe proxy updater now persists installed versions, reconciles older update state, and reports supervisor, installed, activated, and pending versions through runtime and CLI status. Tests cover precedence and fallback behavior, and the unit test script runs the updater suite. ChangesProxy version and update status
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
✅ Single Commit Policy - COMPLIANTStatus: Policy requirements met • 1 commit • Valid format • Ready for merge 📊 View validation details📝 Commit Details
✅ Validation Results
🤖 Automated validation by NeuroLink Single Commit Enforcement |
🤖 AI Review & Build Compliance ✅Status: AI analysis complete • Build rules validated • Ready for review 📊 View detailed analysis results🛡️ Analysis Complete
📋 Ready for Merge When
🤖 AI analysis complete - check individual code comments for specific feedback |
There was a problem hiding this comment.
Pull request overview
This PR improves the proxy auto-updater’s status reporting by separating “installed/validated” versions from “activated/running” versions, and by surfacing richer activation context (supervisor + rolling handoff) without breaking legacy fields.
Changes:
- Persist a new
installedVersionin updater state and backfill it when loading state files. - Persist and expose a
supervisorVersion, plus additional/statusfields (installedVersion,activatedVersion,pendingActivationVersion,activationMode, etc.). - Update CLI
proxy statusoutput and tests to reflect the expanded status shape.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| test/proxyUpdaterFallback.test.ts | Extends updater fallback tests to cover installedVersion and new /status fields. |
| src/lib/types/proxy.ts | Adds installedVersion to the exported UpdateState type. |
| src/lib/types/cli.ts | Extends supervisor state typing with an optional version field. |
| src/lib/proxy/updateState.ts | Persists installedVersion, backfills it on load, and records it on install/success. |
| src/cli/commands/proxy.ts | Exposes new auto-update/supervisor fields in /status and improves CLI status reporting. |
Suppressed comments (2)
src/cli/commands/proxy.ts:3655
supervisorVersionis sourced from an unvalidated JSON state file (seeStateFileManager.load()), so it may not be a string in practice. The JSON output and text formatting later assume a string.
Coerce supervisorState?.version to string | null when populating the status object.
workerVersion: null as string | null,
supervisorPid: null as number | null,
supervisorVersion: supervisorState?.version ?? null,
supervisorRunning: false,
src/cli/commands/proxy.ts:3719
- This later assignment reintroduces the same issue as above:
supervisorState?.versionis not validated and may be non-string if the state file is corrupted. Keep the samestring | nullcoercion here as well to avoid inconsistent types between the initial status object and the populated/running status.
status.supervisorPid = supervisorPid ?? null;
status.supervisorRunning = supervisorRunning;
status.supervisorVersion = supervisorState?.version ?? null;
status.rolling = supervisorState?.rolling ?? null;
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Review SummaryThis PR fixes proxy updater activation state reporting by introducing proper tracking of multiple version states:
Files Changed:
Impact Analysis:
Code Quality Assessment:✅ No hardcoded secrets or credentials No issues found. The changes are logically correct, well-tested, properly typed, and follow architectural patterns. Decision: APPROVED |
Review SummaryDecision: APPROVED ✅ Reviewed all 5 changed files for PR #1264 "fix(proxy): report updater activation state truthfully": Files Reviewed
Verification Completed
Impact Analysis
No inline comments needed - all reviewed files are clean. This PR is ready to merge. |
e3c83db to
7f3e96d
Compare
🤖 AI Review & Build Compliance ✅Status: AI analysis complete • Build rules validated • Ready for review 📊 View detailed analysis results🛡️ Analysis Complete
📋 Ready for Merge When
🤖 AI analysis complete - check individual code comments for specific feedback |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@package.json`:
- Line 158: Remove the proxy-updater Vitest command from the test:unit script
and relocate that coverage to the closest relevant continuous test suite,
invoking it through tsx rather than a Vitest runner. Apply the same change to
the related script entries at the referenced location, preserving the existing
test coverage and harness conventions.
In `@src/cli/commands/proxy.ts`:
- Around line 2300-2302: Update the activationMode selection to return
"rolling-handoff" only when rollingSupervisorRunning is true and
supervisorState?.rolling is not null; otherwise preserve "restart". Add a
regression test covering a running legacy supervisor without persisted rolling
state and verify it reports restart mode.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 23c30cf5-747a-45ed-91db-0367d561e6e4
📒 Files selected for processing (6)
package.jsonsrc/cli/commands/proxy.tssrc/lib/proxy/updateState.tssrc/lib/types/cli.tssrc/lib/types/proxy.tstest/proxyUpdaterFallback.test.ts
7f3e96d to
5a8c93f
Compare
🤖 AI Review & Build Compliance ✅Status: AI analysis complete • Build rules validated • Ready for review 📊 View detailed analysis results🛡️ Analysis Complete
📋 Ready for Merge When
🤖 AI analysis complete - check individual code comments for specific feedback |
Tara-ag
left a comment
There was a problem hiding this comment.
🔒 MAJOR: Version comparison logic can produce incorrect results
The installedVersion backfill logic in loadUpdateState() assumes pendingRestartVersion is always newer than lastUpdateVersion without actually comparing them. This fails for cases where lastUpdateVersion is numerically greater (e.g., comparing "9.10.0" vs "9.9.0" lexicographically gives wrong order), or when pendingRestartVersion happens to be older. The current logic could report an outdated version as installed.
Fix: Add explicit semantic version comparison before choosing between pendingRestartVersion and lastUpdateVersion. Use a semver library or implement proper numeric comparison to ensure the newer version is selected. For example:
installedVersion:
typeof candidate.installedVersion === "string"
? candidate.installedVersion
: compareVersions(candidate.pendingRestartVersion, candidate.lastUpdateVersion) > 0
? candidate.pendingRestartVersion
: candidate.lastUpdateVersionwhere compareVersions performs proper semantic versioning comparison rather than string comparison.
|
🔒 MAJOR: Version comparison logic can produce incorrect results The Fix: Add explicit semantic version comparison before choosing between installedVersion:
typeof candidate.installedVersion === "string"
? candidate.installedVersion
: compareVersions(candidate.pendingRestartVersion, candidate.lastUpdateVersion) > 0
? candidate.pendingRestartVersion
: candidate.lastUpdateVersionwhere |
Re: "Version comparison logic can produce incorrect results" — declining, the premise doesn't applyTwo separate problems with this finding. 1. There is no version comparison in the codeThe change is a precedence chain, not a comparison: installedVersion:
typeof candidate.installedVersion === "string"
? candidate.installedVersion
: typeof candidate.pendingRestartVersion === "string"
? candidate.pendingRestartVersion
: typeof candidate.lastUpdateVersion === "string"
? candidate.lastUpdateVersion
: null,Each branch is a 2. The state machine already guarantees the ordering, so a comparison would be redundant — and wrong
A semver comparison would also encode the wrong semantics. Coverage
Happy to reconsider with a concrete reachable state file that breaks the invariant above — but adding |
Review Summary for PR #1264: fix(proxy): report updater activation state truthfullyDecision: APPROVED FindingsNo blocking issues found. This is a clean, additive PR that improves proxy updater state tracking without breaking backward compatibility. Changes OverviewThis PR adds comprehensive support for tracking proxy supervisor state across updates, including:
Impact on existing code
Verified against CLAUDE.md rules
Test CoverageNew tests added to
All test assertions verify correct behavior for both legacy and current state formats. Review Scope: Reviewed all 6 modified files systematically: package.json, src/cli/commands/proxy.ts, src/lib/proxy/updateState.ts, src/lib/types/cli.ts, src/lib/types/proxy.ts, and test/proxyUpdaterFallback.test.ts. The implementation is sound, well-tested, and maintains full backward compatibility while adding valuable tracking capabilities for the proxy auto-update feature. |
Tara-ag
left a comment
There was a problem hiding this comment.
Review Summary for PR #1264: fix(proxy): report updater activation state truthfully
Decision: APPROVED
Findings
No blocking issues found. This is a clean, additive PR that improves proxy updater state tracking without breaking backward compatibility.
Changes Overview
This PR adds comprehensive support for tracking proxy supervisor state across updates, including:
- New
activatedVersionfield to track when an update was actually activated (not just installed) - New
activationModefield ('automatic' | 'manual') - Additional status fields:
supervisorVersion,lastDetectedVersion,pendingActivationVersion - Type improvements:
CliProxyAutoUpdate,SupervisorStatus,SupervisorVersionInfo - Backward compatibility helpers:
normalizeSupervisorState(),isRollingHandoffCapable() - State management improvements in
loadUpdateState()with legacy file backfill logic
Impact on existing code
- Blast radius: Self-contained changes to proxy-related files only
- Breaking changes: None - all new fields are optional and added gracefully
- Type system impact: Adds new types with proper prefixes; no type removals or renames
- Backward compatibility: Fully maintained via defensive state loading and normalization functions
Verified against CLAUDE.md rules
- ✅ Rule 5 (Backward Compatibility): All changes are additive; legacy state files handled gracefully
- ✅ Rule 7 (No interface): All type definitions use
typekeyword - ✅ Rule 9 (Unique type names): Uses
Cli*prefix for CLI types - ✅ Rule 13 (Barrel-only imports): Test imports from barrel file correctly
- ✅ Error handling: Non-string versions and missing fields handled safely
Test Coverage
New tests added to test/proxyUpdaterFallback.test.ts covering:
- Legacy state file parsing and backfill
- Activated version tracking
- Rolling handoff capability detection
- Supervisor version normalization
- Update deferral and failure handling
All test assertions verify correct behavior for both legacy and current state formats.
Review Scope: Reviewed all 6 modified files systematically: package.json, src/cli/commands/proxy.ts, src/lib/proxy/updateState.ts, src/lib/types/cli.ts, src/lib/types/proxy.ts, and test/proxyUpdaterFallback.test.ts.
The implementation is sound, well-tested, and maintains full backward compatibility while adding valuable tracking capabilities for the proxy auto-update feature.
5a8c93f to
883666b
Compare
🤖 AI Review & Build Compliance ✅Status: AI analysis complete • Build rules validated • Ready for review 📊 View detailed analysis results🛡️ Analysis Complete
📋 Ready for Merge When
🤖 AI analysis complete - check individual code comments for specific feedback |
Review SummaryDecision: APPROVED Review Scope: 5 changed files reviewing proxy updater activation state improvements FindingsNo CRITICAL or MAJOR issues found after thorough review of all changes. Impact on Existing Code
File-by-File Analysis
Key Strengths
RecommendationsNone - PR is ready to merge. The changes correctly address the issue of confusing activation state reporting by properly distinguishing between supervisor version, validated installed version, and actual active worker version. |
🛡️ Yama Review Verdict: CHANGES_REQUESTEDSeverity counts — 🔒 CRITICAL: 0 · 🤖 Yama Review Summary
No verified findings were accepted by the review gate. 1 additional claim(s) in the model verdict never passed verification and were quarantined (see ungatedIssues). The verdict reported findings but carried no detail — treat it as unverified and re-run the review or inspect manually. |
883666b to
b81926b
Compare
🤖 AI Review & Build Compliance ✅Status: AI analysis complete • Build rules validated • Ready for review 📊 View detailed analysis results🛡️ Analysis Complete
📋 Ready for Merge When
🤖 AI analysis complete - check individual code comments for specific feedback |
|
🎉 This PR is included in version 10.8.12 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Problem
The rolling updater persists a version after package validation but calls it
pendingRestartVersion. The status surfaces then render every pending activation as a restart, and do not distinguish the supervisor version, validated installed version, and the actual active worker version.Fix
supervisorVersion,lastDetectedVersion,installedVersion,activatedVersion,pendingActivationVersion, andactivationModein/status.pendingRestartVersion,lastUpdateVersion, and other fields for compatibility.Pending handoff, while legacy services remainPending restart.activatedVersionis read from the serving worker, rather than historicallastUpdateVersion, so a rollback cannot be reported as an activation of the wrong version.Verification
pnpm exec vitest run test/proxyUpdaterFallback.test.ts(42 passed)pnpm exec tsc --noEmit --strict --project tsconfig.cli.jsonpnpm run build:clipnpm exec prettier --check ...git diff --checkThe full pre-commit hook was blocked by the repository checkout missing optional
landing/@sveltejs/adapter-vercel;svelte-checkitself reported 0 errors and 0 warnings before that unrelated failure.Summary by CodeRabbit
New Features
Bug Fixes
Tests