Repository navigation
fix: preserve annotation saves with frozen VS Code API - #36
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (2)
🔗 Linked repositories identifiedCodeRabbit considers these linked repositories for cross-repo context during reviews:
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthrough
ChangesAPI 包装对象与保存消息
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to The shared API wrapper and frozen-API save test present no identified merge-blocking issue. Normal checks remain appropriate. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
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 review |
✅ Action performedReview finished.
|
Summary
Fix the annotation-save regression introduced with the v1.22 external-sync timing guard (#31).
VS Code returns a frozen object from
acquireVsCodeApi(). The annotation panel's shared API shim cached that native object directly, whileexternalSync.jsattempted to replacevscode.postMessage. In a real VS Code Webview that assignment does not take effect, sosave/saveModemessages leaveapp.jswithoutimagePathandeditorVersion; the host then drops them inprocessEditorSave().Changes
externalSync.js's save interception and versioning protocol unchangedimagePathandeditorVersionScope
Only the VS Code annotation panel shim and its regression test are changed. No JetBrains code, persistence format, or merge protocol changes.
Validation
Object.freeze()native API: save reaches the host withoutimagePath/editorVersionimagePath: x/frozen.pngandeditorVersion: 1Summary by CodeRabbit