fix(ws): proper websocket handle types - #846
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 4 included reviews per hour; 2 remain after this review. 📝 WalkthroughWalkthroughWebSocket event data and extension APIs now use client and server handle types. Intercepted connection events retain local connection types, and the interceptor module re-exports the intercepted connection type. ChangesWebSocket connection typing
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to No actionable issue is established for the WebSocket typing change; it is mergeable after normal checks. Security Architecture ReviewSecurity architecture risk: 🔵 Low · up to The public types now accept WebSocket handles, but the reviewed interception path still creates and emits its own concrete connections. No new security exposure was established. Compatibility with extensions outside the repository remains uncertain. Retained concerns Security review detailsSecurity Blast Radius
Trust Boundaries and Controls
🚥 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 |
commit: |
Released: v0.45.3 🎉This has been released in v0.45.3. Get these changes by running the following command: Predictable release automation by Release. |
WebSocketNetworkFramecannot be initialized withWebSocket(Client|Server)ConnectionProtocolimplementations msw#2707