tarpc
An RPC framework for Rust with a focus on ease of use.
0.38.0
9.3M downloads/mo
#3226 most downloaded on crates.io
google/tarpc
What this package is like to depend on
Last release 11 days ago
12 Aug 2026
Ships fairly regularly
a new release about every 5 months
Some releases are documented
notes for 26 of 47 stable releases
4 versions withdrawn
withdrawn after publishing
11 years old
51 releases · first in 2016
1 release in the last 12 months
see the full history below
Release timeline
51 releases · Feb 2016 to Aug 2026Releases
latest 51-
0.38.012 Aug 2026 -
0.37.010 Aug 2025Release notes
Open source →Breaking Changes
Opentelemetry and related dependencies were updated to newer versions. This requires users of tarpc with opentelemetry to update their dependencies as well as code that initializes tracer providers. See example-service/ for how to update code.
-
0.36.027 Mar 2025 -
0.35.027 Oct 2024Release notes
Open source →Breaking Changes
context::Context::deadlineandRequest::deadlinetype changed fromSystemTimetoInstantto preserve monotonicity of time and better support devices that can't rely on clocks. During serialization,Instantis converted toDurationin the same way thatSystemTimewas.- Fixed a race condition that could cause an RPC to hang forever during channel shutdown. As part
of this fix, a few changes were made to error types:
- All ChannelError source errors are now wrapped in Arcs, so that the errors can be cloned and sent to all pending requests.
- RpcError::Receive was renamed to RpcError::Transport to accommodate the range of errors that can now be received by the client. Its source error is now a ChannelError.
- RpcError::Send's source error is now the transport error rather than ChannelError::Write(Transport::Error), because ChannelError::Write wasn't adding any additional information.
- Renamed
serde_transport::{tcp,unix}::Connectto{Tcp,Unix}Connectto disambiguate some compiler error messages so that CI workflows can test more combinations of features. - Request hooks were moved from the
Servetrait to an extension trait calledRequestHook.
New Features
serde_transportnow supports listening on TCP and UDS sockets provided by the caller.- Types that
impl Servenow alsoimpl Stub. - Generated
RequestandResponsetypes now support any derive, not just serde. Use like#[tarpc::service(derive = [Clone, Hash])]. tarpc::Requestandtarpc::Responseare no longer non-exhaustive.
-
0.34.030 Dec 2023Release notes
Open source →Breaking Changes
#[tarpc::server]is no more! Service traits now use async fns.Channel::executeno longer spawns request handlers. Async-fn-in-traits makes it impossible to add a Send bound to the future returned byServe::serve. Instead,Channel::executereturns a stream of futures, where each future is a request handler. To achieve the former behavior:channel.execute(server.serve()) .for_each(|rpc| { tokio::spawn(rpc); })
New Features
- Request hooks are added to the serve trait, so that it's easy to hook in cross-cutting functionality like throttling, authorization, etc.
- The Client trait is back! This makes it possible to hook in generic client functionality like load balancing, retries, etc.
-
0.33.003 Apr 2023 -
0.32.024 Mar 2023Release notes
Open source →Breaking Changes
-
As part of a fix to return more channel errors in RPC results, a few error types have changed:
client::RpcError::Disconnectedwas split into the following errors:
- Shutdown: the client was shutdown, either intentionally or due to an error. If due to an error, pending RPCs should see the more specific errors below.
- Send: an RPC message failed to send over the transport. Only the RPC that failed to be sent will see this error.
- Receive: a fatal error occurred while receiving from the transport. All in-flight RPCs will receive this error.
client::ChannelErrorandserver::ChannelErrorare unified intarpc::ChannelError. Previously, server transport errors would not indicate during which activity the transport error occurred. Now, just like the client already was, it will be specific: reading, readying, sending, flushing, or closing.
-
-
0.31.003 Nov 2022Release notes
Open source →New Features
This release adds Unix Domain Sockets to the
serde_transportmodule. To use it, enable the "unix" feature. See the docs for more information. -
0.30.012 Aug 2022Release notes
Open source →Breaking Changes
- Some types that impl Future are now annotated with
#[must_use]. Code that previously created these types but did not use them will now receive a warning. Code that disallows warnings will receive a compilation error.
Fixes
- Servers will more reliably clean up request state for requests with long deadlines when response processing is aborted without sending a response.
Other Changes
TrackedRequestnow contains a response guard that can be used to ensure state cleanup for aborted requests. (This was already handled automatically byInFlightRequests).- When the feature serde-transport is enabled, the crate tokio_serde is now re-exported.
- Some types that impl Future are now annotated with
-
0.29.026 May 2022Release notes
Open source →Breaking Changes
Context.deadlineis now serialized as a Duration. This prevents clock skew from affecting deadline behavior. For more details see https://github.com/google/tarpc/pull/367 and its related issue. -
0.28.007 Apr 2022Release notes
Open source →Breaking Changes
- The minimum supported Rust version has increased to 1.58.0.
- The version of opentelemetry depended on by tarpc has increased to 0.17.0.
-
0.27.209 Oct 2021Release notes
Open source →Fixes
Clients will now close their transport before dropping it. An attempt at a clean shutdown can help the server drop its connections more quickly.
-
0.27.122 Sep 2021Release notes
Open source →Breaking Changes
RPC error type is changing
RPC return types are changing from
Result<Response, io::Error>toResult<Response, tarpc::client::RpcError>.Becaue tarpc is a library, not an application, it should strive to use structured errors in its API so that users have maximal flexibility in how they handle errors. io::Error makes that hard, because it is a kitchen-sink error type.
RPCs in particular only have 3 classes of errors:
- The connection breaks.
- The request expires.
- The server decides not to process the request.
RPC responses can also contain application-specific errors, but from the perspective of the RPC library, those are opaque to the framework, classified as successful responsees.
Open Telemetry
The Opentelemetry dependency is updated to version 0.16.x.
-
0.27.022 Sep 2021 withdrawn -
0.26.220 Apr 2021Nothing published for this version
-
0.26.118 Apr 2021Nothing published for this version
-
0.26.015 Apr 2021Release notes
Open source →New Features
Tracing
tarpc is now instrumented with tracing primitives extended with OpenTelemetry traces. Using a compatible tracing-opentelemetry subscriber like Jaeger, each RPC can be traced through the client, server, amd other dependencies downstream of the server. Even for applications not connected to a distributed tracing collector, the instrumentation can also be ingested by regular loggers like env_logger.
Breaking Changes
Logging
Logged events are now structured using tracing. For applications using a logger and not a tracing subscriber, these logs may look different or contain information in a less consumable manner. The easiest solution is to add a tracing subscriber that logs to stdout, such as tracing_subscriber::fmt.
Context
- Context no longer has parent_span, which was actually never needed, because the context sent in an RPC is inherently the parent context. For purposes of distributed tracing, the client side of the RPC has all necessary information to link the span to its parent; the server side need do nothing more than export the (trace ID, span ID) tuple.
- Context has a new field, SamplingDecision, which has two variants, Sampled and Unsampled. This field can be used by downstream systems to determine whether a trace needs to be exported. If the parent span is sampled, the expectation is that all child spans be exported, as well; to do otherwise could result in lossy traces being exported. Note that if an Openetelemetry tracing subscriber is not installed, the fallback context will still be used, but the Context's sampling decision will always be inherited by the parent Context's sampling decision.
- Context::scope has been removed. Context propagation is now done via tracing's task-local spans. Spans can be propagated across tasks via Span::in_scope. When a service receives a request, it attaches an Opentelemetry context to the local Span created before request handling, and this context contains the request deadline. This span-local deadline is retrieved by Context::current, but it cannot be modified so that future Context::current calls contain a different deadline. However, the deadline in the context passed into an RPC call will override it, so users can retrieve the current context and then modify the deadline field, as has been historically possible.
- Context propgation precedence changes: when an RPC is initiated, the current Span's Opentelemetry context takes precedence over the trace context passed into the RPC method. If there is no current Span, then the trace context argument is used as it has been historically. Note that Opentelemetry context propagation requires an Opentelemetry tracing subscriber to be installed.
Server
- The server::Channel trait now has an additional required associated type and method which returns the underlying transport. This makes it more ergonomic for users to retrieve transport-specific information, like IP Address. BaseChannel implements Channel::transport by returning the underlying transport, and channel decorators like Throttler just delegate to the Channel::transport method of the wrapped channel.
Client
- NewClient::spawn no longer returns a result, as spawn can't fail.
References
- https://github.com/tokio-rs/tracing
- https://opentelemetry.io
- https://github.com/open-telemetry/opentelemetry-rust/tree/main/opentelemetry-jaeger
- https://github.com/env-logger-rs/env_logger
-
0.25.111 Mar 2021Nothing published for this version
-
0.25.011 Mar 2021 withdrawnRelease notes
Open source →Breaking Changes
Major server module refactoring
- Renames
Some of the items in this module were renamed to be less generic:
- Handler => Incoming
- ClientHandler => Requests
- ResponseHandler => InFlightRequest
- Channel::{respond_with => requests}
In the case of Handler: handler of what? Now it's a bit clearer that this is a stream of Channels (aka incoming connections).
Similarly, ClientHandler was a stream of requests over a single connection. Hopefully Requests better reflects that.
ResponseHandler was renamed InFlightRequest because it no longer contains the serving function. Instead, it is just the request, plus the response channel and an abort hook. As a result of this, Channel::respond_with underwent a big change: it used to take the serving function and return a ClientHandler; now it has been renamed Channel::requests and does not take any args.
- Execute methods
All methods thats actually result in responses being generated have been consolidated into methods named
execute:- InFlightRequest::execute returns a future that completes when a response has been generated and sent to the server Channel.
- Requests::execute automatically spawns response handlers for all requests over a single channel.
- Channel::execute is a convenience for
channel.requests().execute(). - Incoming::execute automatically spawns response handlers for all requests over all channels.
- Removal of Server.
server::Server was removed, as it provided no value over the Incoming/Channel abstractions. Additionally, server::new was removed, since it just returned a Server.
Client RPC methods now take &self
This required the breaking change of removing the Client trait. The intent of the Client trait was to facilitate the decorator pattern by allowing users to create their own Clients that added behavior on top of the base client. Unfortunately, this trait had become a maintenance burden, consistently causing issues with lifetimes and the lack of generic associated types. Specifically, it meant that Client impls could not use async fns, which is no longer tenable today, with channel libraries moving to async fns.
Servers no longer send deadline-exceed responses.
The deadline-exceeded response was largely redundant, because the client shouldn't normally be waiting for such a response, anyway -- the normal client will automatically remove the in-flight request when it reaches the deadline.
This also allows for internalizing the expiration+cleanup logic entirely within BaseChannel, without having it leak into the Channel trait and requiring action taken by the Requests struct.
Clients no longer send cancel messages when the request deadline is exceeded.
The server already knows when the request deadline was exceeded, so the client didn't need to inform it.
Fixes
- When a channel is dropped, all in-flight requests for that channel are now aborted.
-
0.24.128 Dec 2020 -
0.24.028 Dec 2020 withdrawn -
0.23.130 Oct 2020Nothing published for this version
-
0.23.019 Oct 2020 -
0.22.020 Aug 2020Release notes
Open source →This release adds some flexibility and consistency to
serde_transport, with one new feature and one small breaking change.New Features
serde_transport::tcpnow exposes framing configuration onconnect()andlisten(). This is useful if, for instance, you want to send requests or responses that are larger than the maximum payload allowed by default:let mut transport = tarpc::serde_transport::tcp::connect(server_addr, Json::default); transport.config_mut().max_frame_length(4294967296); let mut client = MyClient::new(client::Config::default(), transport.await?).spawn()?;Breaking Changes
The codec argument to
serde_transport::tcp::connectchanged from a Codec to impl Fn() -> Codec, to be consistent withserde_transport::tcp::listen. While only one Codec is needed, more than one person has been tripped up by the inconsistency betweenconnectandlisten. Unfortunately, the compiler errors are not much help in this case, so it was decided to simply do the more intuitive thing so that the compiler doesn't need to step in in the first place. -
0.21.103 Aug 2020Release notes
Open source →New Features
#[tarpc::server] diagnostics
When a service impl uses #[tarpc::server], only
async fns are re-written. This can lead to confusing compiler errors about missing associated types:error: not all trait items implemented, missing: `HelloFut` --> $DIR/tarpc_server_missing_async.rs:9:1 | 9 | impl World for HelloServer { | ^^^^The proc macro now provides better diagnostics for this case:
error: not all trait items implemented, missing: `HelloFut` --> $DIR/tarpc_server_missing_async.rs:9:1 | 9 | impl World for HelloServer { | ^^^^ error: hint: `#[tarpc::server]` only rewrites async fns, and `fn hello` is not async --> $DIR/tarpc_server_missing_async.rs:10:5 | 10 | fn hello(name: String) -> String { | ^^Bug Fixes
Fixed client hanging when server shuts down
Previously, clients would ignore when the read half of the transport was closed, continuing to write requests. This didn't make much sense, because without the ability to receive responses, clients have no way to know if requests were actually processed by the server. It basically just led to clients that would hang for a few seconds before shutting down. This has now been corrected: clients will immediately shut down when the read-half of the transport is closed.
More docs.rs documentation
Previously, docs.rs only documented items enabled by default, notably leaving out documentation for tokio and serde features. This has now been corrected: docs.rs should have documentation for all optional features.
-
0.21.027 Jun 2020Release notes
Open source →New Features
A new proc macro,
#[tarpc::server]was added! This enables service impls to elide the boilerplate of specifying associated types for each RPC. With the ubiquity of async-await, most code won't have nameable futures and will just be boxing the return type anyway. This macro does that for you.Breaking Changes
- Enums had
_non_exhaustivefields replaced with the #[non_exhaustive] attribute.
Bug Fixes
-
https://github.com/google/tarpc/issues/304
A race condition in code that limits number of connections per client caused occasional panics.
-
https://github.com/google/tarpc/pull/295
Made request timeouts account for time spent in the outbound buffer. Previously, a large outbound queue would lead to requests not timing out correctly.
- Enums had
-
0.20.012 Dec 2019Release notes
Open source →Breaking Changes
- tarpc has updated its tokio dependency to the latest 0.2 version.
- The tarpc crates have been unified into just
tarpc, with new Cargo features to enable functionality.- The bincode-transport and json-transport crates are deprecated and superseded by
the
serde_transportmodule, which unifies much of the logic present in both crates.
- The bincode-transport and json-transport crates are deprecated and superseded by
the
-
0.19.021 Sep 2019Nothing published for this version
-
0.18.011 May 2019Nothing published for this version
-
0.17.030 Apr 2019Nothing published for this version
-
0.16.016 Apr 2019Nothing published for this version
-
0.15.027 Mar 2019Nothing published for this version
-
0.14.129 Oct 2018Nothing published for this version
-
0.14.029 Oct 2018Nothing published for this version
-
0.13.017 Oct 2018Release notes
Open source →Breaking Changes
Version 0.13 marks a significant departure from previous versions of tarpc. The API has changed significantly. The tokio-proto crate has been torn out and replaced with a homegrown rpc framework. Additionally, the crate has been modularized, so that the tarpc crate itself contains only the macro code.
New Crates
- crate rpc contains the core client/server request-response framework, as well as a transport trait.
- crate bincode-transport implements a transport that works almost exactly as tarpc works today (not to say it's wire-compatible).
- crate trace has some foundational types for tracing. This isn't really fleshed out yet, but it's useful for in-process log tracing, at least.
All crates are now at the top level. e.g. tarpc-plugins is now tarpc/plugins rather than tarpc/src/plugins. tarpc itself is now a very small code surface, as most functionality has been moved into the other more granular crates.
New Features
- deadlines: all requests specify a deadline, and a server will stop processing a response when past its deadline.
- client cancellation propagation: when a client drops a request, the client sends a message to the server informing it to cancel its response. This means cancellations can propagate across multiple server hops.
- trace context stuff as mentioned above
- more server configuration for total connection limits, per-connection request limits, etc.
Removals
- no more shutdown handle. I left it out for now because of time and not being sure what the right solution is.
- all async now, no blocking stub or server interface. This helps with maintainability, and async/await makes async code much more usable. The service trait is thusly renamed Service, and the client is renamed Client.
- no built-in transport. Tarpc is now transport agnostic (see bincode-transport for transitioning existing uses).
- going along with the previous bullet, no preferred transport means no TLS support at this time. We could make a tls transport or make bincode-transport compatible with TLS.
- a lot of examples were removed because I couldn't keep up with maintaining all of them. Hopefully the ones I kept are still illustrative.
- no more plugins!
-
0.12.113 Aug 2018Nothing published for this version
-
0.12.012 Jul 2018Nothing published for this version
-
0.11.011 Apr 2018Nothing published for this version
-
0.9.018 Sep 2017 -
0.8.006 May 2017Release notes
Open source →Breaking Changes
This release updates tarpc to use serde 1.0. As such, users must also update to use serde 1.0. The serde 1.0 release notes detail migration paths.
-
0.7.326 Apr 2017Release notes
Open source →This release removes the
Syncbound on RPC args for both sync and future clients. No breaking changes. -
0.7.222 Apr 2017Release notes
Open source →Breaking Changes
This release updates tarpc-plugins to work with rustc master. Thus, older versions of rustc are no longer supported. We chose a minor version bump because it is still source-compatible with existing code using tarpc.
-
0.7.131 Mar 2017 -
0.7.031 Mar 2017Nothing published for this version
-
0.6.007 Aug 2016Nothing published for this version
-
0.5.129 Jul 2016 withdrawnNothing published for this version
-
0.5.025 Apr 2016Nothing published for this version
-
0.4.003 Apr 2016Nothing published for this version
-
0.3.020 Feb 2016Nothing published for this version
-
0.2.015 Feb 2016Nothing published for this version
-
0.1.012 Feb 2016Nothing published for this version