Add anthropics/connect-rust plugin v0.4.2

[iainmcgin]

Adds the protoc-gen-connect-rust plugin for ConnectRPC Rust service bindings, under the new top-level anthropics org as requested in earlier review.

Stacked on #2333. This branch includes the anthropics/buffa:v0.5.2 commit so the deps: reference resolves locally; the actual diff for this PR is the second commit. I'll rebase onto main once #2333 merges.

About connect-rust

connect-rust is a Tower-based Rust implementation of the ConnectRPC protocol:

• Three protocols: Connect, gRPC, gRPC-Web - same service impl handles all three
• Full conformance: 3600 server tests, 2580/1454/2838 client tests across Connect/gRPC/gRPC-Web
• Zero-copy request handling via buffa view types - request.name is a &str borrow into the decoded buffer
• Tower integration: composes with axum, hyper, tower middleware

Crates on crates.io: connectrpc, connectrpc-codegen, connectrpc-build.

Plugin layering

The plugin emits service stubs only - server traits, typed clients, monomorphic dispatchers. Message types come from buf.build/anthropics/buffa (declared in deps:). Generated stubs reference message types via absolute Rust paths configured with extern_path.

With file_per_package (set in opts), the plugin emits one <dotted.package>.rs file per proto package, mirroring the anthropics/buffa plugin's file_per_package=true opt. Matches the prost/tonic filename convention the BSR Rust SDK lib.rs synthesis already understands.

Dockerfile note: the protoc-gen-connect-rust binary is a [[bin]] target inside the connectrpc-codegen crate, so cargo install connectrpc-codegen is what produces it.

Open question: extern_path injection — plugin.sum not yet checked in

The plugin needs to know where the buffa-generated message types live so it can emit absolute paths. It accepts either extern_path=.=<rust_path> (same format as tonic/prost) or the shorthand buffa_module=<rust_path>. Without one of these, generation fails:

Error: type .pet.v1.GetPetRequest is not covered by any extern_path mapping.
Add extern_path=.=<your_buffa_module> (e.g. extern_path=.=crate::proto) to the plugin opts.

The tests/ harness runs the plugin standalone with only the opts from buf.plugin.yaml, so make test PLUGINS=anthropics/connect-rust fails at this step and I haven't checked in plugin.sum files yet.

I'd like to understand how the BSR Rust SDK pipeline handles the deps: relationship so I can set the right opt:

• If buffa and connect-rust output are composited into a single SDK crate (as I believe happens for prost+tonic), the right value is something like buffa_module=crate or similar — but then the <dotted.pkg>.rs filenames from the two plugins would collide and one would need a distinguishing suffix (the way tonic emits <pkg>.tonic.rs). Happy to add that to protoc-gen-connect-rust if so.
• If the buffa SDK is a separate crate that the connect-rust SDK depends on, the right value is buffa_module=::<buffa_sdk_crate_name> — but the crate name is dynamic per BSR module, so the BSR would need to inject it.

Can you confirm which model the BSR uses, and what — if anything — it injects into a dependent plugin's opts at SDK build time? Once I know I'll set the opt (or add a testOverrideOptions entry like prost-crate's no_features), regenerate, and check in plugin.sum.

Dependencies

Depends on the buffa plugin landing first: #2333

[bufdev]

#2333 (comment)

[iainmcgin]

changed to crate ref instead of github ref 👍

[stefanvanburen]

should be fine to leave this empty, and the BSR will figure out extern_path settings using the prost syntax 👍.

[stefanvanburen]

silly non-expert-in-rust question: I see the default features; those don't include the tls feature, but is that just something that is "enabled" by having the various "deps" in the sub-features installed? (Mostly trying to confirm that someone consuming this generated SDK could still use the TLS features.)

[iainmcgin]

[claude code] Yes — Cargo features are additive and unified per-crate across the dependency graph. The generated SDK crate only needs connectrpc's default features for the generated code to compile, so that's all it declares. A consumer who wants TLS adds their own direct dependency in their application's Cargo.toml:

connectrpc = { version = "0.4", features = ["tls"] }

Cargo then compiles connectrpc once with the union of features requested by both the SDK crate and the application, so tls (and client-tls / server-tls / any other optional feature) is fully available. Same model the tonic SDK crates use — the SDK doesn't gate runtime features.

[iainmcgin]

[claude code] Updated to protoc-gen-connect-rust v0.4.2 with file_per_package set in opts and the deps plugin reference bumped to anthropics/buffa:v0.5.2. The branch is now stacked on #2333.

I haven't been able to check in plugin.sum files yet — generation fails without an extern_path/buffa_module opt, and I'm not sure what value to put there. The PR description has the details, but in short: I need to know whether the BSR cargo SDK pipeline composites a dep chain (buffa + connect-rust) into one crate or separate crates, and whether it injects an extern_path opt for the dep's types the way I'd assumed it does for tonic→prost. @stefanvanburen / @pkwarren — could you confirm, or point me at a doc/example?