fix: cut websocket throughput in half by pruning activity payloads - #4622
Effect Service Conventions: No findings
All clear
Details
Note
Your check run agent prompt is: .macroscope/check-run-agents/effect-service-conventions.md
More information about how Check Run Agents work can be found in our Help Center.
This PR adds a pure payload-projection helper module (apps/server/src/orchestration/ActivityPayloadProjection.ts) and wires it into existing HTTP (http.ts) and WebSocket (ws.ts) call sites, plus a test. It does not create, move, refactor, or introduce an Effect service, so the Effect service conventions (service definition order, Context.Service, make/layer, dependency acquisition, tagged errors) do not apply to any new construct here.
Checks performed:
- The new module contains only pure, synchronous helper functions with no Effect imports, no
Context.Servicetag, nomake/layer, and no runtime boundaries (ManagedRuntime.make,runPromise). Named type imports from@t3tools/contractsare explicitly permitted for whole packages, and named function imports of a pure-helper module are appropriate (it is not a service module). http.tsandws.tscontinue to import Effect library modules as namespaces (e.g.import * as Effect from "effect/Effect") and only add named imports of the pure projection helpers plus call sites; no service definition, error, or layer conventions are affected.- No new tagged errors, predicates,
Layer.succeed, or service-instance injection were introduced.
No convention violations found in the changed scope.
🔍 Agent activity — reasoning, no tool calls
💭 Looking at this PR, I'm checking whether it introduces any new Effect services. The new
ActivityPayloadProjection.tsfile contains only pure TypeScript helper functions with no Effect imports, and the modifications to the existing files just call these projection functions. The test imports follow the established conventions, so I need to verify this aligns with the project's guidelines. The imports in http.ts and ws.ts follow the convention since ActivityPayloadProjection is a pure helper module, not an Effect service. This PR doesn't violate any Effect service conventions—it's just adding a pure projection helper with appropriate imports. The projection module is a pure helper with no Effect service involved, so named imports from the contracts are fine. Since this PR doesn't create, move, or refactor any Effect services—just pure projection functions—the service conventions don't apply here.
Agent Credits: 27 credits