fix(rpc): make RpcSerialization.msgPack options configurable

[bohdanbirdie]

Fixes #6170

Summary

• Adds makeMsgPack(options) factory for creating MessagePack serialization with custom msgpackr options
• Existing msgPack and layerMsgPack exports are unchanged (no breaking change)
• Fixes silent error swallowing in msgPack decode — non-incomplete errors are now rethrown instead of returning []

Problem

On Cloudflare Workers with allow_eval_during_startup (default for compatibility_date >= 2025-06-01), RpcSerialization.msgPack silently fails when decoding messages containing 3+ objects with the same key structure.

Root cause: new Packr() with no options sets this.structures = [] because undefined != false evaluates to true. This enables msgpackr's record/structure path. When the Unpackr's readObject.count exceeds the JIT threshold (2), msgpackr calls new Function() to compile a fast reader — which CF Workers blocks during request handling with EvalError: Code generation from strings disallowed for this context.

The existing catch { return [] } in RpcSerialization.msgPack silently swallows this error, returning an empty response. The caller never receives data.

Reproduction

https://github.com/bohdanbirdie/repro-effect-rpc-msgpack-cf-workers

• main branch — "before" state: reproduces the bug using inline msgpackr code (same as RpcSerialization.msgPack)
• fixed branch — "after" state: uses bun patch on @effect/rpc to apply this PR's changes, worker uses RpcSerialization.makeMsgPack({ useRecords: false })

Deploy either branch to CF Workers with npx wrangler deploy and curl the endpoint.

Fix

Use makeMsgPack to create a serialization with custom options:

import { Layer } from "effect"
import { RpcSerialization } from "@effect/rpc"

Layer.succeed(
  RpcSerialization,
  RpcSerialization.makeMsgPack({ useRecords: false })
)

This skips this.structures = [] in the Packr constructor, preventing the record/JIT path entirely.

Test plan

• New unit tests for msgPack and makeMsgPack with custom options
• Existing 101 e2e RpcServer tests pass (http, ws, tcp, worker × ndjson, msgpack, jsonrpc)
• CF Workers deployment verified with { useRecords: false }

References

• livestore PR with full investigation
• CF Workers new Function() restriction docs
• msgpackr useRecords docs
• CF allow_eval_during_startup compat flag

[changeset-bot]

🦋 Changeset detected

Latest commit: 964bb3d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 13 packages

Name	Type
@effect/rpc	Patch
@effect/cluster	Patch
@effect/platform-bun	Patch
@effect/platform-node-shared	Patch
@effect/platform-node	Patch
@effect/workflow	Patch
@effect/ai	Patch
@effect/sql-clickhouse	Patch
@effect/ai-amazon-bedrock	Patch
@effect/ai-anthropic	Patch
@effect/ai-google	Patch
@effect/ai-openai	Patch
@effect/ai-openrouter	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[bohdanbirdie]

I'm not sure if the solution is good enough, but I think that the underlying issue is confirmed. I'm rather new to effect so PR changes might need some guidance, but I'm happy to carry on with it.

Reproduction repository should be easy to use and try.

Tim, let me know what you think (didn't want to ping and create noise).

[IGassmann]

FYI, msgpackr has landed an upstream fix that wraps the new Function() call in a try/catch, falling back to the interpreted path when it's blocked. Once that's released and @effect/rpc updates its msgpackr dependency, this would fix #6169 without needing { useRecords: false }.

That said, the configurable makeMsgPack(options) API and the decode error-swallowing fix in this PR are still valuable independently.

[IGassmann]

The upstream fix has been released in msgpackr 1.11.10 (see kriszyp/msgpackr#179). I've opened #6191 to bump the minimum msgpackr version to ^1.11.10, which resolves the Cloudflare Workers issue without needing configurable options or the no-eval entry point.