What version of Effect is running?
@effect/rpc 0.75.0
What steps can reproduce the bug?
The decode function in RpcSerialization.msgPack catches all errors from unpackr.unpackMultiple() and returns an empty array for any non-incomplete error:
decode: (bytes) => {
// ...
try {
return unpackr.unpackMultiple(buf)
} catch (error_) {
const error = error_ as any
if (error.incomplete) {
incomplete = buf.subarray(error.lastPosition)
return error.values ?? []
}
return [] // ← all other errors silently return empty array
}
}Any error that isn't an incomplete chunking error — corrupted data, encoding mismatches, runtime restrictions on new Function() (see #6169) — is silently discarded. The caller receives an empty array as if no messages were sent.
What is the expected behavior?
Non-incomplete decode errors should propagate (or at minimum be logged). These represent genuine failures — corrupted data, incompatible serialization settings, or environment restrictions — not expected chunking boundaries.
What do you see instead?
Errors are silently swallowed and an empty array is returned. RPC calls fail with no indication of what went wrong, making debugging extremely difficult. In the case of #6169, this masked the root cause for weeks.
Additional information
The incomplete error handling is correct and necessary — msgpackr uses it for chunked stream processing. But the catch-all return [] fallback conflates expected chunking with unexpected failures.
What version of Effect is running?
@effect/rpc0.75.0What steps can reproduce the bug?
The
decodefunction inRpcSerialization.msgPackcatches all errors fromunpackr.unpackMultiple()and returns an empty array for any non-incompleteerror:Any error that isn't an
incompletechunking error — corrupted data, encoding mismatches, runtime restrictions onnew Function()(see #6169) — is silently discarded. The caller receives an empty array as if no messages were sent.What is the expected behavior?
Non-
incompletedecode errors should propagate (or at minimum be logged). These represent genuine failures — corrupted data, incompatible serialization settings, or environment restrictions — not expected chunking boundaries.What do you see instead?
Errors are silently swallowed and an empty array is returned. RPC calls fail with no indication of what went wrong, making debugging extremely difficult. In the case of #6169, this masked the root cause for weeks.
Additional information
The
incompleteerror handling is correct and necessary — msgpackr uses it for chunked stream processing. But the catch-allreturn []fallback conflates expected chunking with unexpected failures.