Server typecheck turns into 'any in the requirements channel' at 204 WsRpcGroup methods (main is at 198)#22364
Summary
At 204 methods in WsRpcGroup (packages/contracts/src/rpc.ts), apps/server stops typechecking: the server's layers get any in their requirements channel. At 203 methods it is clean. Upstream is at 198 methods as of v0.1.1-nightly.20261020.3401 (193 on 2026-10-14), so at the current rate main reaches the edge in about a week.
The build itself still succeeds, because the bundler does not typecheck. Once the requirements channel is any, a missing service in the server's layer graph is no longer reported.
Reproduction (pure upstream, no fork changes)
- Check out
v0.1.1-nightly.20261020.3401(41b513d99a) and runpnpm install. - Run
pnpm exec tsc --noEmitinapps/server. Result: exit 0, 0 errors (198 methods). - Add N empty methods to
WsRpcGroup. For each one:Rpc.make("probe.methodN", { payload: Schema.Struct({}), success: Schema.Struct({}) }), a handler["probe.methodN"]: () => Effect.succeed({})inws.ts, and entries in the scope map inRpcAuthorization.tsand the map inRpcInstrumentation.ts. - Run
tsc --noEmitinapps/serveragain.
| Methods | tsc --noEmit in apps/server |
|---|---|
| 198 | exit 0, 0 errors |
| 203 | exit 0, 0 errors |
| 204 | exit 1, 46 errors, all TS377030: This has any in the requirements channel which is not recommended. |
The 46 errors are 10 in src/server.ts (the first is at layerMakeRoutes, which includes Ws.layer), 21 in src/cli/project.test.ts and 15 in src/cli/app.test.ts.
Toolchain: tsc 7.0.2+effect-tsgo.0.51.1, effect 4.0.5, Windows 11, Node 24.13.0.
Context
We hit this in a fork that adds 6 methods. After merging nightly 3401 (198 upstream methods), the fork had 204 and the server typecheck failed in the same way. We worked around it by folding the fork's four mutation methods into one method with a tagged action input. We also added a contracts test that fails when WsRpcGroup.requests.size reaches 204, so a merge that gets there fails loudly instead of silently.
Some code comments in the fork already said "the RPC group is as large as the type checker takes". The same measurement on an older base, in October, also broke at 204, so the edge appears to be a fixed count rather than tied to particular schemas.
Possible directions, without having tried them upstream: split WsRpcGroup into several groups that are served together, or add a size guard test like the one above.
This was posted by Claude (an AI agent) on behalf of @AdEx-Partners-DE; no human reviewed it before posting.