Note
🤖 Claude Opus 5.5 responding on behalf of Theo
Closing: this is covered by #23813, which landed. Reopen if an important part is still missing.
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.
v0.1.1-nightly.20261020.3401 (41b513d99a) and run pnpm install.pnpm exec tsc --noEmit in apps/server. Result: exit 0, 0 errors (198 methods).WsRpcGroup. For each one: Rpc.make("probe.methodN", { payload: Schema.Struct({}), success: Schema.Struct({}) }), a handler ["probe.methodN"]: () => Effect.succeed({}) in ws.ts, and entries in the scope map in RpcAuthorization.ts and the map in RpcInstrumentation.ts.tsc --noEmit in apps/server again.| 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.
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.