Repository navigation
fix(capabilities): require refresh after client updates - #4373
Conversation
|
Warning Review limit reached
Next review available in: 4 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: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe client now detects stale registered capability elements after package updates, marks affected modules as ChangesCapability client refresh
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant CapabilityModuleLoader
participant CustomElementsRegistry
participant CapabilityElement
participant Browser
CapabilityModuleLoader->>CustomElementsRegistry: Check registered custom element
CapabilityModuleLoader->>CapabilityElement: Publish refresh-required status
CapabilityElement->>Browser: Reload page on refresh action
Possibly related PRs
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/client/src/hooks/use-capability-packages.ts (1)
169-202: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winTrack in-flight client imports per package version.
If
installed.datachanges fromv1tov2while a/client?v=${v1}import is pending, the current loop can acceptv2as ready after thev1module registersmarinara-capability-${item.id}. If the package later unregisters/re-registers or throws for the duplicate,v2can end up stuck or failed despite the constructor already present. Keep per-package in-flight state so a later version completion that arrives after a tag is already registered publishes"refresh-required"instead of accepting the stale constructor.🤖 Prompt for 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. In `@packages/client/src/hooks/use-capability-packages.ts` around lines 169 - 202, Update the client-import flow around capabilityClientNeedsRefresh and loadedClientModules to track in-flight imports per package version, rather than treating a registered custom-element tag as sufficient for every later version. When an older import completes after a newer installed version is observed and its tag is already registered, publish "refresh-required" for the newer version instead of marking it ready; preserve existing ready/error handling for imports matching the tracked version and clear the in-flight state when each import settles.
🤖 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.
Outside diff comments:
In `@packages/client/src/hooks/use-capability-packages.ts`:
- Around line 169-202: Update the client-import flow around
capabilityClientNeedsRefresh and loadedClientModules to track in-flight imports
per package version, rather than treating a registered custom-element tag as
sufficient for every later version. When an older import completes after a newer
installed version is observed and its tag is already registered, publish
"refresh-required" for the newer version instead of marking it ready; preserve
existing ready/error handling for imports matching the tracked version and clear
the in-flight state when each import settles.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 50f07dbd-201a-4de1-ad29-d2ee72750999
📒 Files selected for processing (6)
package.jsonpackages/client/src/components/capabilities/CapabilityElement.tsxpackages/client/src/hooks/use-capability-packages.tspackages/client/src/lib/capability-client-version.tspackages/client/src/localization/locales/en.jsonscripts/regressions/capability-client-version-refresh.regression.ts
|
@coderabbitai review |
✅ Action performedReview finished.
|
1 participant
Closes #4372
Why this change
An already-open browser tab cannot replace a registered custom-element constructor when a downloaded capability package updates. Marinara imported the new module and reported it as ready, but continued rendering the old client implementation until the user happened to refresh the page. This made World Maps 1.2.3 appear to be missing its shared-world Game Setup action even though the installed and served artifact contained it.
What changed
Validation
pnpm checkpnpm localization:checkgit diff --checkManual verification