pyRPCv0.14.1 is a patch release that fixes batch requests in the FastAPI adapter. If you were using httpBatchLink with a FastAPI backend, your batch requests were being silently rejected before they ever reached pyRPC.
What was broken
The FastAPI adapter's /rpc endpoint annotated its payload as dict[str, Any]. FastAPI uses that annotation for Pydantic validation before your endpoint function runs. When httpBatchLink sends a JSON array of operations, FastAPI sees an array where it expects a dict and returns a 422 error.
The core handle_request function has supported batch requests since v0.13.0. The bug was exclusively in how the FastAPI adapter surfaced the payload.
The fix
One line in pyrpc_fastapi/__init__.py:
# Before (broken for batch):
async def rpc_endpoint(payload: dict[str, Any]):
# After:
async def rpc_endpoint(payload: dict[str, Any] | list[dict[str, Any]]):FastAPI now accepts both single operations (dict) and batch operations (list of dicts), matching what handle_request actually accepts.
Why other adapters were fine
Flask, Django, and the ASGI adapter all use raw JSON parsing (request.get_json(), json.loads(body)). They pass whatever the HTTP body contains directly to handle_request without framework-level type validation. Only FastAPI adds its own validation gate via type annotations.
Upgrade
uv add pyrpc-fastapi@0.14.1No breaking changes. If you were working around this by using httpLink instead of httpBatchLink, you can switch back to batching now.