Feat/websocket controller#462
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR introduces WebSocket and WebSocket-fetch controller support across the tegg framework: new decorators, types, and metadata builders in ChangesWebSocket controller support
Estimated code review effort: 5 (Critical) | ~120 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
core/controller-decorator/src/decorator/websocket-fetch/WebSocketFetchController.tsESLint skipped: missing config or dependency (missing-dependency). The ESLint configuration references a package that is not available in the sandbox. core/controller-decorator/src/decorator/websocket-fetch/WebSocketFetchMethod.tsESLint skipped: the ESLint configuration for this file references a package that is not available in the sandbox. core/controller-decorator/src/decorator/websocket/WebSocketController.tsESLint skipped: the ESLint configuration for this file references a package that is not available in the sandbox.
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 |
|
Dependency limit exceeded — report not shown. This pull request scan exceeded the 10,000-dependency limit applied to this scan, so the results are incomplete and may be inaccurate. To avoid reporting false positives, Socket has not posted a report. Upgrade your plan to raise the dependency limit and get complete reports, or view the partial scan in the dashboard. Socket is always free for open source. If this is a non-commercial open source project, contact us to request a free Team account. |
There was a problem hiding this comment.
Code Review
This pull request introduces comprehensive WebSocket and WebSocket Fetch controller support to the Egg/Tegg framework, including new decorators, metadata builders, and runtime registers for both standard Egg applications and standalone service workers. The review feedback highlights critical areas for improvement: eagerly rejecting unmatched upgrade requests with a 404 in the WebSocket register blocks other plugins and should be avoided; stream handling in both standard and standalone registers suffers from event listener leaks on stream settlement; and a missing path assertion in the fetch controller builder can lead to cryptic validation errors.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Nitpick comments (3)
plugin/controller/lib/impl/websocket/WebSocketControllerRegister.ts (1)
517-591: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚖️ Poor tradeoffConsider sharing the websocket-fetch stream helpers
sendFetchResponseStream,destroyFetchResponseStream*, andrejectSocketare still duplicated acrossplugin/controller/lib/impl/websocket/WebSocketControllerRegister.tsandstandalone/service-worker/src/websocket/WebSocketControllerRegister.ts. A shared helper would reduce drift; pass the logger/error formatter in so the two implementations can keep their current logging behavior.🤖 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 `@plugin/controller/lib/impl/websocket/WebSocketControllerRegister.ts` around lines 517 - 591, Share the duplicated websocket-fetch stream logic between the two WebSocketControllerRegister implementations by extracting sendFetchResponseStream, destroyFetchResponseStream(s), and rejectSocket into a common helper. Pass logger and error-formatting dependencies into the helper so each caller preserves its existing logging behavior, then replace both local implementations with the shared helper and update call sites.standalone/service-worker/src/websocket/WebSocketControllerRegister.ts (2)
502-557: 📐 Maintainability & Code Quality | 🔵 Trivial | 🏗️ Heavy liftSignificant duplication with the plugin
WebSocketControllerRegister.
sendFetchResponseStream,destroyFetchResponseStream,isReadableStream,buildMethodArgs, andcomposeare nearly identical toplugin/controller/lib/impl/websocket/WebSocketControllerRegister.ts. The primary difference is logging (console.errorvsthis.app.logger.error). Extracting shared logic into a common module would reduce maintenance burden and ensure bug fixes propagate to both implementations.Also applies to: 559-576, 596-615
🤖 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 `@standalone/service-worker/src/websocket/WebSocketControllerRegister.ts` around lines 502 - 557, Extract the duplicated helpers sendFetchResponseStream, destroyFetchResponseStream, isReadableStream, buildMethodArgs, and compose from both WebSocketControllerRegister implementations into a shared module, then update each class to use it. Preserve existing behavior while allowing logging to be injected or adapted so standalone code continues using console.error and the plugin implementation uses this.app.logger.error.
502-557: 🚀 Performance & Scalability | 🔵 Trivial | 🏗️ Heavy lift
sendFetchResponseStreamdoes not handle WebSocket backpressure.Data is read from the source stream via
result.on('data', onData)in flowing mode and sent withwebSocket.send()without checkingbufferedAmount. If the client is slow to consume, data accumulates in ws's internal send buffer, potentially causing unbounded memory growth. In contrast,pipeResponseStream(line 596) usespipeline()which handles backpressure correctly. Consider usingpipeline()or pausing/resuming the source stream based onwebSocket.bufferedAmount.🤖 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 `@standalone/service-worker/src/websocket/WebSocketControllerRegister.ts` around lines 502 - 557, sendFetchResponseStream reads in flowing mode without respecting WebSocket backpressure, allowing bufferedAmount to grow unboundedly. Refactor the stream forwarding around sendFetchResponseStream to use pipeline-compatible backpressure handling, or pause the readable source whenever webSocket.bufferedAmount exceeds a defined threshold and resume it once the buffer drains; preserve existing completion, error handling, cleanup, and responseStreams tracking.
🤖 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
`@core/controller-decorator/src/impl/websocket/WebSocketControllerMetaBuilder.ts`:
- Line 38: Correct the assertion message in WebSocketControllerMetaBuilder by
changing the text in the controller type assertion to “invalid controller type.”
In
`@plugin/controller/test/fixtures/apps/controller-app/app/controller/WebSocketController.ts`:
- Line 164: Replace the empty callback passed to pipeline in WebSocketController
with a callback containing a descriptive comment, satisfying the
`@typescript-eslint/no-empty-function` lint rule while preserving behavior.
In `@standalone/service-worker/package.json`:
- Line 57: Update the ws dependency in package.json from ^8.18.0 to ^8.21.0 or a
newer non-vulnerable version, leaving `@types/ws` unchanged.
In `@standalone/service-worker/src/websocket/WebSocketControllerRegister.ts`:
- Around line 154-161: Update WebSocketControllerRegister.rejectSocket to
replace the socket.write() followed by socket.destroy() sequence with
socket.end(), passing the complete HTTP error response so the data is flushed
before the connection closes.
- Around line 483-490: Ensure errors from controllerMeta.connectionMethod or
controllerMeta.openMethod do not bypass awaiting closeHandled: restructure the
try/finally flow around invokeMethod so await closeHandled always executes
before rethrowing any connection/open error, while preserving
resolveControllerReady() in the finally block and propagating the original error
afterward.
In `@standalone/service-worker/test/fixtures/websocket/WebSocketController.ts`:
- Line 145: Replace the empty callback passed to pipeline in WebSocketController
with a non-empty error handler that logs or otherwise acknowledges the received
error, preserving existing stream error propagation while satisfying ESLint’s
no-empty-function rule.
In `@standalone/service-worker/test/websocket/websocket.test.ts`:
- Around line 287-293: Remove the unused waitJSONMessages function from the
websocket tests; callers already use createJSONMessageQueue, so delete the
definition to resolve no-unused-vars failures.
---
Nitpick comments:
In `@plugin/controller/lib/impl/websocket/WebSocketControllerRegister.ts`:
- Around line 517-591: Share the duplicated websocket-fetch stream logic between
the two WebSocketControllerRegister implementations by extracting
sendFetchResponseStream, destroyFetchResponseStream(s), and rejectSocket into a
common helper. Pass logger and error-formatting dependencies into the helper so
each caller preserves its existing logging behavior, then replace both local
implementations with the shared helper and update call sites.
In `@standalone/service-worker/src/websocket/WebSocketControllerRegister.ts`:
- Around line 502-557: Extract the duplicated helpers sendFetchResponseStream,
destroyFetchResponseStream, isReadableStream, buildMethodArgs, and compose from
both WebSocketControllerRegister implementations into a shared module, then
update each class to use it. Preserve existing behavior while allowing logging
to be injected or adapted so standalone code continues using console.error and
the plugin implementation uses this.app.logger.error.
- Around line 502-557: sendFetchResponseStream reads in flowing mode without
respecting WebSocket backpressure, allowing bufferedAmount to grow unboundedly.
Refactor the stream forwarding around sendFetchResponseStream to use
pipeline-compatible backpressure handling, or pause the readable source whenever
webSocket.bufferedAmount exceeds a defined threshold and resume it once the
buffer drains; preserve existing completion, error handling, cleanup, and
responseStreams tracking.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: ca0177ad-3acd-4861-9b7b-1912af57b83a
📒 Files selected for processing (52)
core/controller-decorator/index.tscore/controller-decorator/src/decorator/http/HTTPParam.tscore/controller-decorator/src/decorator/websocket-fetch/WebSocketFetchController.tscore/controller-decorator/src/decorator/websocket-fetch/WebSocketFetchMethod.tscore/controller-decorator/src/decorator/websocket-fetch/WebSocketFetchParam.tscore/controller-decorator/src/decorator/websocket/WebSocketController.tscore/controller-decorator/src/decorator/websocket/WebSocketMethod.tscore/controller-decorator/src/decorator/websocket/WebSocketParam.tscore/controller-decorator/src/impl/websocket-fetch/WebSocketFetchControllerMetaBuilder.tscore/controller-decorator/src/impl/websocket-fetch/WebSocketFetchControllerMethodMetaBuilder.tscore/controller-decorator/src/impl/websocket/WebSocketControllerMetaBuilder.tscore/controller-decorator/src/impl/websocket/WebSocketControllerMethodMetaBuilder.tscore/controller-decorator/src/model/WebSocketControllerMeta.tscore/controller-decorator/src/model/WebSocketFetchControllerMeta.tscore/controller-decorator/src/model/WebSocketFetchMethodMeta.tscore/controller-decorator/src/model/WebSocketMethodMeta.tscore/controller-decorator/src/model/index.tscore/controller-decorator/src/util/WebSocketInfoUtil.tscore/test-util/StandaloneTestUtil.tscore/types/controller-decorator/MetadataKey.tscore/types/controller-decorator/WebSocketContext.tscore/types/controller-decorator/WebSocketController.tscore/types/controller-decorator/WebSocketFetchController.tscore/types/controller-decorator/WebSocketFetchMethod.tscore/types/controller-decorator/WebSocketFetchParam.tscore/types/controller-decorator/WebSocketMethod.tscore/types/controller-decorator/WebSocketParam.tscore/types/controller-decorator/index.tscore/types/controller-decorator/model/types.tscore/types/standalone/index.tscore/types/standalone/websocket.tsplugin/controller/app.tsplugin/controller/lib/impl/websocket/WebSocketContext.tsplugin/controller/lib/impl/websocket/WebSocketControllerRegister.tsplugin/controller/package.jsonplugin/controller/test/fixtures/apps/controller-app/app/controller/AppController.tsplugin/controller/test/fixtures/apps/controller-app/app/controller/WebSocketController.tsplugin/controller/test/fixtures/apps/controller-app/app/controller/WebSocketTestState.tsplugin/controller/test/websocket/websocket.test.tsplugin/controller/test/websocket/websocketCluster.test.tsstandalone/service-worker/index.tsstandalone/service-worker/package.jsonstandalone/service-worker/src/ServiceWorkerApp.tsstandalone/service-worker/src/hook/ControllerLoadUnitHook.tsstandalone/service-worker/src/websocket/ServiceWorkerWebSocketContext.tsstandalone/service-worker/src/websocket/WebSocketControllerRegister.tsstandalone/service-worker/src/websocket/WebSocketEventHandler.tsstandalone/service-worker/test/fixtures/http/GetController.tsstandalone/service-worker/test/fixtures/websocket/WebSocketController.tsstandalone/service-worker/test/fixtures/websocket/package.jsonstandalone/service-worker/test/http/response.test.tsstandalone/service-worker/test/websocket/websocket.test.ts
Code Review: Feat/websocket controller总览本 PR 为 tegg 在三层架构(types → decorator → meta builder → register)上引入了完整的 WebSocket 支持,整体设计与现有 HTTP Controller 体系保持一致:
整体架构方向正确,运行时逻辑写得比较细致(消息串行队列、按连接清理流、settle 时移除 listener 等)。以下问题按重要性排序。 主要问题1. 两份 Register 之间约 660 行代码重复(可维护性,高优先级)
2. Egg 插件模式下未匹配的 upgrade 请求会永久挂起(资源泄漏 / DoS 风险)
3. fetch 模式的响应流没有背压处理(内存风险)
4. 所有 HTTP 参数装饰器现在无条件写入 WebSocket 元数据
5. 普通 WebSocket 模式的 message 回调中访问 ContextProto 是个陷阱(需要文档)
次要问题
测试覆盖e2e 层面很强:插件单进程(609 行)、双 worker cluster、standalone 三套用例,包含不少 tricky 场景(生命周期错误 → error handler → 1011 关闭、按连接销毁流、消息顺序)。缺口:
结论架构方向正确、运行时代码用心。建议合并前修复问题 2(未匹配 upgrade 挂起),并对问题 1(代码重复)至少给出后续重构计划确认;问题 3–5 也强烈建议在合并前处理。文档目前缺失,而这是面向用户的 feature。 |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
plugin/controller/lib/impl/websocket/WebSocketControllerRegister.ts (1)
135-143: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winMisleading non-null assertion on
checkRouters.get(host)The
!assertion onthis.checkRouters.get(host)!is immediately contradicted by theif (!router)check on the next line. The value can beundefinedfor new hosts — the assertion is incorrect. Using a separately typed local variable would be clearer and type-safe.♻️ Proposed refactor
hosts.forEach(host => { - router = this.checkRouters.get(host)!; - if (!router) { - router = new EggRouter({ sensitive: true }, {} as any); - this.checkRouters.set(host, router); - } - this.checkDuplicateInRouter(router, controllerMeta, methodMeta); - this.registerToRouter(router, controllerMeta, methodMeta); + let hostRouter = this.checkRouters.get(host); + if (!hostRouter) { + hostRouter = new EggRouter({ sensitive: true }, {} as any); + this.checkRouters.set(host, hostRouter); + } + this.checkDuplicateInRouter(hostRouter, controllerMeta, methodMeta); + this.registerToRouter(hostRouter, controllerMeta, methodMeta); });🤖 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 `@plugin/controller/lib/impl/websocket/WebSocketControllerRegister.ts` around lines 135 - 143, Remove the non-null assertion from the `this.checkRouters.get(host)` assignment in the `hosts.forEach` callback, keeping `router` typed as possibly undefined so the existing `if (!router)` initialization and subsequent router registration remain type-safe.
🧹 Nitpick comments (2)
core/websocket-runtime/test/WebSocketRouteRegistry.test.ts (1)
12-63: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd tests for
WebSocketFetchControllerMetabranch and host port matching.The test only covers
WebSocketControllerMeta. The helper functions'ControllerType.WEBSOCKET_FETCHbranches (lines 82, 92, 102, 112 inWebSocketRouteRegistry.ts) andmatchWebSocketHostport-stripping logic (line 139) are untested. Adding a fetch-controller test case and a host-with-port match (e.g.,example.com:8080matchingexample.com) would close this gap.🤖 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 `@core/websocket-runtime/test/WebSocketRouteRegistry.test.ts` around lines 12 - 63, The existing WebSocket route test covers only WebSocketControllerMeta and omits fetch-controller and host-port behavior. Extend the test around createWebSocketRoutes and matchWebSocketRoute with a WebSocketFetchControllerMeta case that exercises the ControllerType.WEBSOCKET_FETCH branches, and add a host-with-port assertion confirming example.com:8080 matches the example.com route while preserving the existing coverage.core/websocket-runtime/src/WebSocketRouteRegistry.ts (1)
75-113: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider reducing repetitive type-narrowing boilerplate.
Four helper functions (
getWebSocketMethodRealPath,getWebSocketMethodHosts,getWebSocketMethodName,getWebSocketMethodMiddlewares) share the identicalif (controllerMeta.type === ControllerType.WEBSOCKET) { ... } else { ... }pattern withascasts. A single dispatch helper or moving the union-type handling into the metadata classes would reduce duplication and the risk of the branches diverging.♻️ Optional refactor: single dispatch helper
+function dispatchMethodMeta<R>( + controllerMeta: WebSocketControllerMetadata, + methodMeta: WebSocketRouteMethodMeta, + wsFn: (m: WebSocketMethodMeta) => R, + fetchFn: (m: WebSocketFetchMethodMeta) => R, +): R { + return controllerMeta.type === ControllerType.WEBSOCKET + ? wsFn(methodMeta as WebSocketMethodMeta) + : fetchFn(methodMeta as WebSocketFetchMethodMeta); +} + export function getWebSocketMethodRealPath( controllerMeta: WebSocketControllerMetadata, methodMeta: WebSocketRouteMethodMeta, ) { - if (controllerMeta.type === ControllerType.WEBSOCKET) { - return controllerMeta.getMethodRealPath(methodMeta as WebSocketMethodMeta); - } - return controllerMeta.getMethodRealPath(methodMeta as WebSocketFetchMethodMeta); + return dispatchMethodMeta( + controllerMeta, methodMeta, + m => controllerMeta.getMethodRealPath(m), + m => controllerMeta.getMethodRealPath(m), + ); }🤖 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 `@core/websocket-runtime/src/WebSocketRouteRegistry.ts` around lines 75 - 113, Reduce the duplicated type-narrowing branches shared by getWebSocketMethodRealPath, getWebSocketMethodHosts, getWebSocketMethodName, and getWebSocketMethodMiddlewares by introducing a single dispatch helper or equivalent metadata-level union handling. Preserve each helper’s existing behavior and return types while centralizing the ControllerType.WEBSOCKET distinction and its casts.
🤖 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 `@core/websocket-runtime/src/WebSocketFetchSession.ts`:
- Around line 57-71: Update WebSocketFetchSession.onClose to preserve or log any
buffered error events before replacing the events queue and enqueueing the close
event. Ensure pending errors are handled consistently with onError, while
retaining the existing dropped-message tracking and connection/open event
behavior.
---
Outside diff comments:
In `@plugin/controller/lib/impl/websocket/WebSocketControllerRegister.ts`:
- Around line 135-143: Remove the non-null assertion from the
`this.checkRouters.get(host)` assignment in the `hosts.forEach` callback,
keeping `router` typed as possibly undefined so the existing `if (!router)`
initialization and subsequent router registration remain type-safe.
---
Nitpick comments:
In `@core/websocket-runtime/src/WebSocketRouteRegistry.ts`:
- Around line 75-113: Reduce the duplicated type-narrowing branches shared by
getWebSocketMethodRealPath, getWebSocketMethodHosts, getWebSocketMethodName, and
getWebSocketMethodMiddlewares by introducing a single dispatch helper or
equivalent metadata-level union handling. Preserve each helper’s existing
behavior and return types while centralizing the ControllerType.WEBSOCKET
distinction and its casts.
In `@core/websocket-runtime/test/WebSocketRouteRegistry.test.ts`:
- Around line 12-63: The existing WebSocket route test covers only
WebSocketControllerMeta and omits fetch-controller and host-port behavior.
Extend the test around createWebSocketRoutes and matchWebSocketRoute with a
WebSocketFetchControllerMeta case that exercises the
ControllerType.WEBSOCKET_FETCH branches, and add a host-with-port assertion
confirming example.com:8080 matches the example.com route while preserving the
existing coverage.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 63ada958-3098-4ef3-a07d-6d581e91235d
📒 Files selected for processing (41)
core/controller-decorator/src/decorator/websocket-fetch/WebSocketFetchController.tscore/controller-decorator/src/decorator/websocket-fetch/WebSocketFetchMethod.tscore/controller-decorator/src/decorator/websocket/WebSocketController.tscore/controller-decorator/src/decorator/websocket/WebSocketMethod.tscore/controller-decorator/src/impl/websocket-fetch/WebSocketFetchControllerMetaBuilder.tscore/controller-decorator/src/impl/websocket-fetch/WebSocketFetchControllerMethodMetaBuilder.tscore/controller-decorator/src/impl/websocket/WebSocketControllerMetaBuilder.tscore/controller-decorator/src/impl/websocket/WebSocketControllerMethodMetaBuilder.tscore/controller-decorator/src/model/WebSocketControllerMeta.tscore/controller-decorator/src/model/WebSocketFetchControllerMeta.tscore/controller-decorator/src/model/WebSocketFetchMethodMeta.tscore/controller-decorator/src/model/WebSocketMethodMeta.tscore/controller-decorator/src/util/WebSocketInfoUtil.tscore/controller-decorator/test/websocket/WebSocketMeta.test.tscore/types/controller-decorator/WebSocketContext.tscore/types/controller-decorator/WebSocketController.tscore/types/controller-decorator/WebSocketFetchController.tscore/types/controller-decorator/WebSocketFetchMethod.tscore/types/controller-decorator/WebSocketMethod.tscore/websocket-runtime/index.tscore/websocket-runtime/package.jsoncore/websocket-runtime/src/WebSocketControllerRuntime.tscore/websocket-runtime/src/WebSocketFetchSession.tscore/websocket-runtime/src/WebSocketRouteRegistry.tscore/websocket-runtime/test/WebSocketFetchSession.test.tscore/websocket-runtime/test/WebSocketRouteRegistry.test.tscore/websocket-runtime/tsconfig.jsoncore/websocket-runtime/tsconfig.pub.jsonplugin/controller/app.tsplugin/controller/lib/impl/websocket/WebSocketContext.tsplugin/controller/lib/impl/websocket/WebSocketControllerRegister.tsplugin/controller/package.jsonplugin/controller/test/fixtures/apps/controller-app/app/controller/WebSocketController.tsplugin/controller/test/fixtures/apps/controller-app/config/config.default.jsplugin/controller/test/websocket/websocket.test.tsplugin/controller/test/websocket/websocketCluster.test.tsstandalone/service-worker/package.jsonstandalone/service-worker/src/websocket/ServiceWorkerWebSocketContext.tsstandalone/service-worker/src/websocket/WebSocketControllerRegister.tsstandalone/service-worker/test/fixtures/websocket/WebSocketController.tsstandalone/service-worker/test/websocket/websocket.test.ts
💤 Files with no reviewable changes (1)
- plugin/controller/app.ts
🚧 Files skipped from review as they are similar to previous changes (19)
- core/types/controller-decorator/WebSocketFetchController.ts
- core/controller-decorator/src/decorator/websocket-fetch/WebSocketFetchController.ts
- core/types/controller-decorator/WebSocketController.ts
- core/controller-decorator/src/model/WebSocketFetchMethodMeta.ts
- core/controller-decorator/src/decorator/websocket/WebSocketMethod.ts
- standalone/service-worker/src/websocket/ServiceWorkerWebSocketContext.ts
- core/types/controller-decorator/WebSocketFetchMethod.ts
- core/controller-decorator/src/decorator/websocket/WebSocketController.ts
- core/types/controller-decorator/WebSocketMethod.ts
- standalone/service-worker/package.json
- core/controller-decorator/src/impl/websocket/WebSocketControllerMetaBuilder.ts
- core/controller-decorator/src/model/WebSocketControllerMeta.ts
- core/controller-decorator/src/impl/websocket-fetch/WebSocketFetchControllerMetaBuilder.ts
- core/controller-decorator/src/decorator/websocket-fetch/WebSocketFetchMethod.ts
- core/controller-decorator/src/impl/websocket-fetch/WebSocketFetchControllerMethodMetaBuilder.ts
- plugin/controller/test/websocket/websocketCluster.test.ts
- core/controller-decorator/src/model/WebSocketMethodMeta.ts
- core/controller-decorator/src/impl/websocket/WebSocketControllerMethodMetaBuilder.ts
- plugin/controller/test/fixtures/apps/controller-app/app/controller/WebSocketController.ts
Checklist
npm testpassesAffected core subsystem(s)
Description of change
Summary by CodeRabbit