Surface plugin update availability on the plugins page - #421
Conversation
The plugin manager page already showed each installed plugin's version and
had an Update button, but nothing told users an update actually existed —
they had to guess. The store manager already compares the installed
manifest version against the registry's latest_version for its reinstall
decision; this surfaces that same signal in the UI.
- api_v3 /plugins/installed now returns `latest_version` (from the registry
cache, no extra network call) and an `update_available` flag computed by a
new semver-aware helper `_is_plugin_update_available`. A locally modified
plugin whose version is ahead of the registry is not flagged.
- The installed-plugin card shows "vX.Y.Z available" next to the installed
version, and the Update button becomes emphasized ("Update to vX.Y.Z" with
a gentle pulse) when a newer version is published — mirroring the app's own
update banner styling.
- Added tests for the helper and the endpoint fields.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_012EW8yDbsk8EceDpq6Hjgqj
|
Warning Review limit reached
Next review available in: 54 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. 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: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe installed-plugin API now exposes ChangesInstalled plugin updates
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant PluginManagerUI
participant InstalledPluginsAPI
participant PluginRegistry
PluginManagerUI->>InstalledPluginsAPI: Request installed plugins
InstalledPluginsAPI->>PluginRegistry: Read latest_version and verified
PluginRegistry-->>InstalledPluginsAPI: Return registry metadata
InstalledPluginsAPI-->>PluginManagerUI: Return update_available and latest_version
PluginManagerUI->>PluginManagerUI: Render badge and update control
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 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 |
Up to standards ✅🟢 Issues
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@web_interface/blueprints/api_v3.py`:
- Around line 136-139: Update the exception handler around _parse_version in the
version comparison logic to catch packaging.version.InvalidVersion specifically
instead of Exception, importing or referencing that exception as needed while
preserving the existing fallback behavior.
🪄 Autofix (Beta)
❌ Autofix failed (check again to retry)
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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 6f7e195c-6188-4c87-a09c-f3cba4c41ffb
📒 Files selected for processing (4)
test/test_web_api.pyweb_interface/blueprints/api_v3.pyweb_interface/static/v3/app.cssweb_interface/static/v3/plugins_manager.js
Address review feedback: the version comparison caught a blind `except Exception` (ruff BLE001). Split the two failure modes and catch each specifically — ImportError for a missing `packaging` (a core dependency) and InvalidVersion for an unparseable version string — while preserving the existing "surface the mismatch" fallback behavior. Added a test for the unparseable-version path. Co-Authored-By: Claude Opus 4.8 <[email protected]> Claude-Session: https://claude.ai/code/session_012EW8yDbsk8EceDpq6Hjgqj
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. Autofix skipped. No unresolved CodeRabbit review comments with fix instructions found. |
Summary
The plugins page already showed each installed plugin's version and had an Update button, but nothing told users that an update actually existed. This surfaces an "update available" signal — installed version vs. latest published version — right on the plugin card, mirroring how the app already notifies you about its own core updates.
Type of change
Related issues
Test plan
EMULATOR=true python3 run.py)scripts/dev_server.py)pytest) — new + existingtest/test_web_api.pyplugin-installed tests pass; frontend JS passesnode --checkDetails: added unit coverage for the semver comparison helper and endpoint-level tests asserting
latest_version/update_availableappear (and are correctlyTrue/False) in the/plugins/installedresponse.Documentation
CLAUDE.md)Plugin compatibility
The change only adds two fields to the
/plugins/installedresponse and reads the registry's existinglatest_version; no plugin-facing API changes.Checklist
CONTRIBUTING.mdNotes for reviewer
What changed
web_interface/blueprints/api_v3.py—/plugins/installednow returnslatest_version(pulled from the registry cache that's already fetched for theverifiedflag — no extra network call) and anupdate_availableboolean. The boolean comes from a new_is_plugin_update_available()helper that does a PEP 440 / semver-aware comparison so a locally-modified plugin whose version is ahead of the registry is never falsely flagged; it falls back to a plain inequality check for unparseable version strings.web_interface/static/v3/plugins_manager.js— the installed-plugin card shows a "vX.Y.Z available" badge next to the installed version, and the existing Update button becomes emphasized ("Update to vX.Y.Z", blue, gentle pulse) when a newer version exists. The Update button/action itself is unchanged — this just tells the user when to press it.web_interface/static/v3/app.css— pulse animation for the emphasized button, with aprefers-reduced-motionopt-out; reuses the app's existing blue update-banner palette (light + dark).This deliberately reuses the version-comparison concept the store manager already applies for its reinstall decision, rather than introducing a new mechanism.
🤖 Generated with Claude Code
https://claude.ai/code/session_012EW8yDbsk8EceDpq6Hjgqj
Generated by Claude Code
Summary by CodeRabbit
New Features
Accessibility
Bug Fixes