Add simple flag by bufdev · Pull Request #851 · connectrpc/connect-go

bufdev · 2025-06-07T05:48:08Z

This is re: #848 #421.

The general concept is to effectively just model what people know already. The interface is very similar to grpc-go in this case. It's a misuse of context.Context in the general sense, but basically every RPC library (except connect-go, but including grpc-go, which is what people are typically migrating from) does this. This results in unary-only Handler interfaces matching grpc-go and Twirp, and Client interfaces almost matching grpc-go (and matching Twirp). This is (in my opinion) generally a feature, but there are caveats: people using the grpc-go metadata package will be tripped up when migrating, when they realize their headers/trailers aren't being propagated. Given how few people actually interact with headers and trailers, however, this feels like a minor downside that can be documented as part of migration.

A future commit will update the README (we wanted to wait until after a release was created, so users looking at the README wouldn't be confused by it being out-of-sync with the latest release). We'll also follow-up soon with updates to the connectrpc.com docs.

mfridman · 2025-06-07T14:27:33Z

Strong +1 from me.

After a good few years and many servers/clients written for work and personal projects, my take is:

Unfamiliar and verbose migrating from twirp-go/grpc-go
Wrapping with New{Request,Response} is tedious, and so daily ergonomics suffer
Optimizes for the rare case, most code doesn't touch headers. So every call site pays the complexity cost
Context propagation is fine. For the rare times you need headers, passing via context is acceptable!

TL;DR - developer ergonomics matter more (esp. in this case) than avoiding the "context misuse" when that misuse is already the established patterns developers expect.

Signed-off-by: bufdev <bufdev-github@buf.build>

Alfus · 2025-06-08T20:23:02Z

Strong +1 from me as well. Wrapping causes a lot of extra, unneeded boilerplate code.

mattrobenolt · 2025-06-08T22:30:34Z

Generate to a separate package, such as .*connectsimple.

Does it make sense to also use this as an opportunity, likely configurable since I understand why we do it this way currently, given this "simple" interface to generate into the same parent package by default to mirror gRPC behavior?

bufdev · 2025-06-08T22:48:24Z

Speaking for myself, I still feel relatively strongly about generating to a separate package by default, but maybe could be convinced otherwise. I think this was a big miss on grpc-go's part, it sets up a whole host of problems w.r.t. plugin interactions. I get where your mind is though - grpc-go migration, import simplicity.

Note that with the implementation as-is in this PR now, it is just flag-based and generates to the same package as before. And this is configurable via package_suffix, including setting to empty to copy grpc-go semantics of generating to same package. I'd argue to keep it this way - two independent flags - as opposed to introducing special semantics w.r.t package if you set the simple flag.

bufdev · 2025-06-08T22:50:49Z

A separate overall note: the implementation as-is fully allows and supports multiple protoc-gen-connect-go calls to independent packages, so for users who want both interfaces available, this is trivial. In fact, this is what this repository is now doing as of this PR: look at buf.gen.yaml, which generates to internal/gen/generics and internal/gen/simple.

mattrobenolt · 2025-06-08T22:52:35Z

Oh yeah, I agree with the choices entirely to keep it a separate package, but more thinking in lines of expectations that users have.

This API that is being addressed here and the separate packages are the biggest real complains I've observed from discussions.

Even though we agree a separate package is better, I'm more looking at it from a lense of default expectations.

If I'm a user and I want this "simple" API, I likely am just wanting a grpc-go experience to align and be as much drop-in as possible.

I definitely don't hold a strong opinion here tho. I'm just pushing for a flip in the default behavior when opting into this simple API. But I think it's fine either way.

jhump

I'm a little worried about the fact that it generates incompatible code and requires a plugin option. This is mainly an issue for BSR generated SDKs -- we can't change the options used for the "connect-go" generated packages because of back-compat issues. Do you instead anticipate adding a "connect-go-simple" set of SDKs?

What if we generated both always, e.g. PingServiceSimpleClient, PingServiceSimpleHandler?

jhump · 2025-06-09T13:50:30Z

context.go

+// WithStoreResponseHeader returns a new context to be given to a client when making a request
+// that will result in the header pointer being set to the response header.
+func WithStoreResponseHeader(ctx context.Context, header *http.Header) context.Context {


In grpc-go, this accumulates a slice of all pointers for all calls. That way, if it goes through any middleware or other library code, where this is called multiple times, everyone gets back the same headers. With this implementation, the last one will get back the headers and all prior callers will get back nothing.

jhump · 2025-06-09T13:51:16Z

context.go

+
+// WithStoreResponseTrailer returns a new context to be given to a client when making a request
+// that will result in the trailer pointer being set to the response trailer.
+func WithStoreResponseTrailer(ctx context.Context, trailer *http.Header) context.Context {


In addition to the headers and trailers, you also need functions for accessing Spec and Peer.

Instead of mirror the grpc-go API so closely and having all of these loose functions for dealing this stuff, how about we try something a little different and consolidate so that we have fewer free functions. Something like so:

// RequestInfo represents metadata about the current RPC // operation. // // On client-side, RequestHeader returns mutable map for setting // headers before the RPC is invoked. Other values can be inspected // later after RPC completes. // // On server-side, ResponseHeader and ResponseTrailer return // mutable maps for setting response metadata before handler // returns. Other values can be inspected immediately. type RequestInfo interface { Spec() Spec Peer() Peer RequestHeader() http.Header ResponseHeader() http.Header ResponseTrailer() http.Header // unexported method gives us the flexibility to add to this // interface, just like we have in AnyRequest and AnyResponse internalOnly() } // Create a new request context for use from a client. When the returned // context is passed to RPCs, the returned request info can be used to set // request metadata before the RPC is invoked and to inspect response // metadata after the RPC completes. // // The returned context may be re-used across RPCs as long as they are // not concurrent. Results of all RequestInfo methods other than // RequestHeader are undefined if the context is used with concurrent RPCs. // // If the given context is already associated with outgoing RequestInfo, then // ctx and the existing RequestInfo are returned. func NewOutgoingContext(context.Context) (context.Context, RequestInfo) // RequestInfoFromOutgoingContext returns the RequestInfo for the given // context, if there is one. // // Here for completeness, but not really necessary since NewOutgoingContext // can return existing RequestInfo and since interceptors get wrappers for // direct access to request info properties. func RequestInfoFromOutgoingContext(context.Context) (RequestInfo, bool) // RequestInfoFromIncomingContext returns the RequestInfo for the given // context, if there is one. Always returns a value and true for contexts passed // to server interceptors and handlers. func RequestInfoFromIncomingContext(context.Context) (RequestInfo, bool)

This would also resolve the comment about, about needing to accumulate response header/trailer addresses, since NewOutgoingContext can be called more than once before the RPC and all callers get access to the same info.

I like this a lot - much cleaner. I'll work towards this.

jhump · 2025-06-09T14:17:28Z

cmd/protoc-gen-connect-go/main.go


 	switch {
 	case isStreamingClient && !isStreamingServer:
 		g.P("return c.", unexport(method.GoName), ".CallClientStream(ctx)")


I think we will actually want "simple" versions of the client and bidi-stream client interfaces, too. Currently, they allow the caller to set request headers first, and the RPC isn't actually invoked until the first call to stream.Send. But a simple version could omit the RequestHeader() method and immediately invoke the RPC, because the header data can be provided in the context.

I think this will be more intuitive for users because it has been a question in the past (particularly for bidi) for how to send request headers and start the RPC but not send an initial message. Having to call stream.Send(nil) was the work-around, but with "simple" clients, we could resolve that quirk.

bufdev · 2025-06-09T14:23:57Z

Given this isn't a Buf product, I'm not as concerned with that. But with respect to the BSR, Buf would just host it as a new plugin "connect/gosimple" that called this option.

I don't want to add a suffix to the interfaces - that's making the simple interfaces more complicated. Presenting a single package with two different types of clients and handlers makes the problem worse IMO.

jhump · 2025-06-09T14:32:01Z

Coincidentally, this would also solve #850 since it provides a way for unary handlers to explicitly set header or trailer metadata, independent of the metadata set on a returned error.

jhump · 2025-06-09T15:36:17Z

I was thinking a bit more about this: a flag named "simple" may not be the most intuitive way to turn this on. It's not that it's "simpler" than the other way; it's just an alternate approach. While it may feel simpler to not have the wrappers, it's actually less simple/less obvious when you do need to interact with metadata.

So maybe it's more like "metadata_mode=context" and the existing/default behavior is "metadata_mode=wrapper". (I don't particularly like "metadata_mode", but I'm having a hard time deciding what to call it. I similarly don't actually like the name RequestInfo in my other suggestion/proposal, but am not sure what the best name would be...)

bufdev · 2025-06-10T00:53:21Z

I'd have to hard disagree on this one.

The whole thing here is that almost no one interacts with the metadata. It's significantly more complicated for the vast majority of users to have a Request/Response wrapper - if it were simpler to use the existing system, no one would be clamoring for this feature.

The option should be clear, concise, and the closest thing to get users to use it as a suggested default (short of v2'ing connect-go and making it the actual default, which we do not want to do). A boolean option simple accomplishes that.

When I read context vs wrapper as two option values, I do not know what these mean or why I should choose one or the other without reading the docs - and it's a fair assumption that most users won't read the docs. The vast majority of developers will be served best by using the simple API - it gets them what they need, in the way they expect it. Calling this option simple will pull gravity in this direction.

pkwarren · 2025-06-10T19:21:20Z

This looks great - removing the request/response wrappers would remove a lot of boilerplate. My main feedback was related to supporting Peer/Spec and avoiding storing multiple values on the context, but @jhump covered that above: #851 (comment).

This adds the usage of CallInfo in context for issuing requests with the new simple API. This builds on top of the #851 which implements the simple flag for unary and server-streaming In addition, it adds integration tests for the simple and generics API. It also implements the simple approach for client and bidi streams. --------- Signed-off-by: Steve Ayers <sayers@buf.build> Signed-off-by: Joshua Humphries <2035234+jhump@users.noreply.github.com> Signed-off-by: John Chadwick <jchadwick@buf.build>

This is in relation to #851. This standardizes on using `For` instead of `From` for all of our functions. The two words are interchangeable, and all of our public methods use `For`, so this has all of our private methods do so as well. A new public method `CallInfoFromHandler` is/was being introduced in #851, and in relation to renaming it to `CallInfoForHandler`, this furthers the standardization. Signed-off-by: bufdev <bufdev-github@buf.build>

bufdev · 2025-08-14T15:22:42Z

context.go

+func (c *clientCallInfo) internalOnly() {}
+
+type clientCallInfoContextKey struct{}
+type sentinelContextKey struct{}


What is sentinel? I'd expect these to have docs

Signed-off-by: bufdev <bufdev-github@buf.build>

bufdev · 2025-08-14T15:30:40Z

client.go

+// are transmitted when this method is called and do not require an explicit call to [BidiStreamForClient.Send].
+//
+// Likewise, response headers and trailers should be read from the [CallInfo] object in context.
+func (c *Client[Req, Res]) CallBidiStreamSimple(ctx context.Context) (*BidiStreamForClient[Req, Res], error) {


Why is there no corresponding BidiStreamForClientSimple like in ClientStreamForClientSimple? In the latter, you removed the RequestHeader method, but since the former doesn't exist, it is still present in the return value here. I'd argue that likely neither should exist, and .*StreamForClient should handle RequestHeader no matter what, but regardless we should probably be consistent.

Actually maybe both should exist, given that there's no need for connect.Request in one scenario

Yep, apologies. I had this on a separate branch while I was waiting for the docs review so that it didn't over-complicate things. Take a look at #869, which should address your comment here.

bufdev · 2025-08-14T15:32:52Z

client.go

+	if stream.err != nil {
+		return nil, stream.err
+	}
+	if err := stream.Send(nil); err != nil {


Similarly, given that this is the only difference, I'm not sure if it's worth having a separate CallBidiStreamSimple and extra docs just to call stream.Send (assuming you handle RequestHeader no matter what)

This is in relation to connectrpc#851. This standardizes on using `For` instead of `From` for all of our functions. The two words are interchangeable, and all of our public methods use `For`, so this has all of our private methods do so as well. A new public method `CallInfoFromHandler` is/was being introduced in connectrpc#851, and in relation to renaming it to `CallInfoForHandler`, this furthers the standardization. Signed-off-by: bufdev <bufdev-github@buf.build>

…trpc#856) This adds the usage of CallInfo in context for issuing requests with the new simple API. This builds on top of the connectrpc#851 which implements the simple flag for unary and server-streaming In addition, it adds integration tests for the simple and generics API. It also implements the simple approach for client and bidi streams. --------- Signed-off-by: Steve Ayers <sayers@buf.build> Signed-off-by: Joshua Humphries <2035234+jhump@users.noreply.github.com> Signed-off-by: John Chadwick <jchadwick@buf.build> Signed-off-by: Steve Ayers <sayers@buf.build>

This is in relation to connectrpc#851. This standardizes on using `For` instead of `From` for all of our functions. The two words are interchangeable, and all of our public methods use `For`, so this has all of our private methods do so as well. A new public method `CallInfoFromHandler` is/was being introduced in connectrpc#851, and in relation to renaming it to `CallInfoForHandler`, this furthers the standardization. Signed-off-by: bufdev <bufdev-github@buf.build> Signed-off-by: Steve Ayers <sayers@buf.build>

This adds better stream types for bidi streams, making them more consistent with client streaming. Signed-off-by: Steve Ayers <sayers@buf.build>

bufdev · 2025-08-18T20:42:39Z

Looking at the code, I do not understand what sentinelContextKey does - this needs explanation, everything else I think is ready.

smaye81 · 2025-08-19T14:10:49Z

Looking at the code, I do not understand what sentinelContextKey does - this needs explanation, everything else I think is ready.

Added some explanation in #870

This adds docs to the context key structs, specifically expanding on `sentinelContextKey`. --------- Signed-off-by: Steve Ayers <sayers@buf.build> Signed-off-by: bufdev <4228796+bufdev@users.noreply.github.com> Co-authored-by: bufdev <4228796+bufdev@users.noreply.github.com> Co-authored-by: Joshua Humphries <2035234+jhump@users.noreply.github.com>

bufdev · 2025-08-20T19:32:48Z

LGTM! Let's ship it!

jrinehart-buf · 2025-08-20T19:38:43Z

LGTM! Let's ship it!

I'll get the docs PR up to date and ready for review.

staugaard · 2025-09-18T02:13:17Z

When will we see this released?

This PR contains the following updates: | Package | Change | Age | Confidence | |---|---|---|---| | [connectrpc.com/connect](https://github.com/connectrpc/connect-go) | `v1.18.1` -> `v1.19.0` | [![age](https://developer.mend.io/api/mc/badges/age/go/connectrpc.com%2fconnect/v1.19.0?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![confidence](https://developer.mend.io/api/mc/badges/confidence/go/connectrpc.com%2fconnect/v1.18.1/v1.19.0?slim=true)](https://docs.renovatebot.com/merge-confidence/) | --- ### Release Notes <details> <summary>connectrpc/connect-go (connectrpc.com/connect)</summary> ### [`v1.19.0`](https://github.com/connectrpc/connect-go/releases/tag/v1.19.0) [Compare Source](connectrpc/connect-go@v1.18.1...v1.19.0) This release introduces the highly requested "simple" flag for code generation, making Connect significantly more ergonomic for everyday RPC development. The new simple flag in protoc-gen-connect-go generates cleaner, more intuitive client and handler interfaces that eliminate request/response wrappers for most use cases. This addresses community feedback about verbosity and provides a more straightforward API. When enabled, metadata (headers/trailers) can be passed through context instead of explicit wrapper objects, optimizing for the common case where developers don't need direct access to HTTP headers. #### What's Changed ##### Enhancements - Add simple flag for more ergonomic generated code by [@bufdev](https://github.com/bufdev) and [@smaye81](https://github.com/smaye81) in [#851](connectrpc/connect-go#851) - Update Go to v1.24 and document http.Protocol use removing the dependency on `golang.org/x/net/http2` by [@maxbrunet](https://github.com/maxbrunet) in [#873](connectrpc/connect-go#873), [#877](connectrpc/connect-go#877) - Add support for Edition 2024 by [@emcfarlane](https://github.com/emcfarlane) in [#878](connectrpc/connect-go#878) ##### Bugfixes - Include valid spec and headers when calling recover handler for streaming RPCs by [@jhump](https://github.com/jhump) in [#817](connectrpc/connect-go#817) ##### Other changes - Go version support updated to latest two instead of three by [@jhump](https://github.com/jhump) in [#837](connectrpc/connect-go#837) - CI testing improvements by [@pkwarren](https://github.com/pkwarren) and [@jhump](https://github.com/jhump) in [#838](connectrpc/connect-go#838), [#839](connectrpc/connect-go#839) - Code quality improvements by [@mattrobenolt](https://github.com/mattrobenolt) and [@bufdev](https://github.com/bufdev) in [#841](connectrpc/connect-go#841), [#867](connectrpc/connect-go#867) - Documentation improvements by [@adlion](https://github.com/adlion) and [@stefanvanburen](https://github.com/stefanvanburen) in [#821](connectrpc/connect-go#821), [#880](connectrpc/connect-go#880) #### New Contributors - [@adlion](https://github.com/adlion) made their first contribution in [#821](connectrpc/connect-go#821) - [@maxbrunet](https://github.com/maxbrunet) made their first contribution in [#873](connectrpc/connect-go#873) - [@stefanvanburen](https://github.com/stefanvanburen) made their first contribution in [#880](connectrpc/connect-go#880) **Full Changelog**: <connectrpc/connect-go@v1.18.1...v1.19.0> </details> --- ### Configuration 📅 **Schedule**: Branch creation - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC), Automerge - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).  Co-authored-by: Earl Warren <contact@earl-warren.org> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9425 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Renovate Bot <forgejo-renovate-action@forgejo.org> Co-committed-by: Renovate Bot <forgejo-renovate-action@forgejo.org>

emcfarlane · 2025-09-26T14:35:35Z

@staugaard this has been released in v1.19.0

This PR contains the following updates: | Package | Change | Age | Confidence | |---|---|---|---| | [connectrpc.com/connect](https://github.com/connectrpc/connect-go) | `v1.18.1` -> `v1.19.0` | [![age](https://developer.mend.io/api/mc/badges/age/go/connectrpc.com%2fconnect/v1.19.0?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![confidence](https://developer.mend.io/api/mc/badges/confidence/go/connectrpc.com%2fconnect/v1.18.1/v1.19.0?slim=true)](https://docs.renovatebot.com/merge-confidence/) | --- ### Release Notes <details> <summary>connectrpc/connect-go (connectrpc.com/connect)</summary> ### [`v1.19.0`](https://github.com/connectrpc/connect-go/releases/tag/v1.19.0) [Compare Source](connectrpc/connect-go@v1.18.1...v1.19.0) This release introduces the highly requested "simple" flag for code generation, making Connect significantly more ergonomic for everyday RPC development. The new simple flag in protoc-gen-connect-go generates cleaner, more intuitive client and handler interfaces that eliminate request/response wrappers for most use cases. This addresses community feedback about verbosity and provides a more straightforward API. When enabled, metadata (headers/trailers) can be passed through context instead of explicit wrapper objects, optimizing for the common case where developers don't need direct access to HTTP headers. #### What's Changed ##### Enhancements - Add simple flag for more ergonomic generated code by [@bufdev](https://github.com/bufdev) and [@smaye81](https://github.com/smaye81) in [#851](connectrpc/connect-go#851) - Update Go to v1.24 and document http.Protocol use removing the dependency on `golang.org/x/net/http2` by [@maxbrunet](https://github.com/maxbrunet) in [#873](connectrpc/connect-go#873), [#877](connectrpc/connect-go#877) - Add support for Edition 2024 by [@emcfarlane](https://github.com/emcfarlane) in [#878](connectrpc/connect-go#878) ##### Bugfixes - Include valid spec and headers when calling recover handler for streaming RPCs by [@jhump](https://github.com/jhump) in [#817](connectrpc/connect-go#817) ##### Other changes - Go version support updated to latest two instead of three by [@jhump](https://github.com/jhump) in [#837](connectrpc/connect-go#837) - CI testing improvements by [@pkwarren](https://github.com/pkwarren) and [@jhump](https://github.com/jhump) in [#838](connectrpc/connect-go#838), [#839](connectrpc/connect-go#839) - Code quality improvements by [@mattrobenolt](https://github.com/mattrobenolt) and [@bufdev](https://github.com/bufdev) in [#841](connectrpc/connect-go#841), [#867](connectrpc/connect-go#867) - Documentation improvements by [@adlion](https://github.com/adlion) and [@stefanvanburen](https://github.com/stefanvanburen) in [#821](connectrpc/connect-go#821), [#880](connectrpc/connect-go#880) #### New Contributors - [@adlion](https://github.com/adlion) made their first contribution in [#821](connectrpc/connect-go#821) - [@maxbrunet](https://github.com/maxbrunet) made their first contribution in [#873](connectrpc/connect-go#873) - [@stefanvanburen](https://github.com/stefanvanburen) made their first contribution in [#880](connectrpc/connect-go#880) **Full Changelog**: <connectrpc/connect-go@v1.18.1...v1.19.0> </details> --- ### Configuration 📅 **Schedule**: Branch creation - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC), Automerge - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).  Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1029 Reviewed-by: earl-warren <earl-warren@noreply.code.forgejo.org> Co-authored-by: Renovate Bot <bot@kriese.eu> Co-committed-by: Renovate Bot <bot@kriese.eu>

This PR contains the following updates: | Package | Change | Age | Confidence | |---|---|---|---| | [connectrpc.com/connect](https://github.com/connectrpc/connect-go) | `v1.18.1` -> `v1.19.1` | [![age](https://developer.mend.io/api/mc/badges/age/go/connectrpc.com%2fconnect/v1.19.1?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![confidence](https://developer.mend.io/api/mc/badges/confidence/go/connectrpc.com%2fconnect/v1.18.1/v1.19.1?slim=true)](https://docs.renovatebot.com/merge-confidence/) | --- ### Release Notes <details> <summary>connectrpc/connect-go (connectrpc.com/connect)</summary> ### [`v1.19.1`](https://github.com/connectrpc/connect-go/releases/tag/v1.19.1) [Compare Source](connectrpc/connect-go@v1.19.0...v1.19.1)  #### What's Changed ##### Bugfixes - Fix bounds check on envelope for 32-bit archs by [@emcfarlane](https://github.com/emcfarlane) in [#887](connectrpc/connect-go#887) - Fix CallInfo header/trailer propagation on error responses by [@emcfarlane](https://github.com/emcfarlane) in [#892](connectrpc/connect-go#892) **Full Changelog**: <connectrpc/connect-go@v1.19.0...v1.19.1> ### [`v1.19.0`](https://github.com/connectrpc/connect-go/releases/tag/v1.19.0) [Compare Source](connectrpc/connect-go@v1.18.1...v1.19.0) This release introduces the highly requested "simple" flag for code generation, making Connect significantly more ergonomic for everyday RPC development. The new simple flag in protoc-gen-connect-go generates cleaner, more intuitive client and handler interfaces that eliminate request/response wrappers for most use cases. This addresses community feedback about verbosity and provides a more straightforward API. When enabled, metadata (headers/trailers) can be passed through context instead of explicit wrapper objects, optimizing for the common case where developers don't need direct access to HTTP headers. #### What's Changed ##### Enhancements - Add simple flag for more ergonomic generated code by [@bufdev](https://github.com/bufdev) and [@smaye81](https://github.com/smaye81) in [#851](connectrpc/connect-go#851) - Update Go to v1.24 and document http.Protocol use removing the dependency on `golang.org/x/net/http2` by [@maxbrunet](https://github.com/maxbrunet) in [#873](connectrpc/connect-go#873), [#877](connectrpc/connect-go#877) - Add support for Edition 2024 by [@emcfarlane](https://github.com/emcfarlane) in [#878](connectrpc/connect-go#878) ##### Bugfixes - Include valid spec and headers when calling recover handler for streaming RPCs by [@jhump](https://github.com/jhump) in [#817](connectrpc/connect-go#817) ##### Other changes - Go version support updated to latest two instead of three by [@jhump](https://github.com/jhump) in [#837](connectrpc/connect-go#837) - CI testing improvements by [@pkwarren](https://github.com/pkwarren) and [@jhump](https://github.com/jhump) in [#838](connectrpc/connect-go#838), [#839](connectrpc/connect-go#839) - Code quality improvements by [@mattrobenolt](https://github.com/mattrobenolt) and [@bufdev](https://github.com/bufdev) in [#841](connectrpc/connect-go#841), [#867](connectrpc/connect-go#867) - Documentation improvements by [@adlion](https://github.com/adlion) and [@stefanvanburen](https://github.com/stefanvanburen) in [#821](connectrpc/connect-go#821), [#880](connectrpc/connect-go#880) #### New Contributors - [@adlion](https://github.com/adlion) made their first contribution in [#821](connectrpc/connect-go#821) - [@maxbrunet](https://github.com/maxbrunet) made their first contribution in [#873](connectrpc/connect-go#873) - [@stefanvanburen](https://github.com/stefanvanburen) made their first contribution in [#880](connectrpc/connect-go#880) **Full Changelog**: <connectrpc/connect-go@v1.18.1...v1.19.0> </details> --- ### Configuration 📅 **Schedule**: Branch creation - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC), Automerge - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).  Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1078 Reviewed-by: earl-warren <earl-warren@noreply.code.forgejo.org> Co-authored-by: Renovate Bot <bot@kriese.eu> Co-committed-by: Renovate Bot <bot@kriese.eu>

bufdev requested review from emcfarlane and jhump June 7, 2025 05:48

bufdev force-pushed the simple branch 7 times, most recently from f53e429 to 6423e79 Compare June 8, 2025 02:00

Prototype simple flag

49f43a7

Signed-off-by: bufdev <bufdev-github@buf.build>

bufdev force-pushed the simple branch from 6423e79 to 49f43a7 Compare June 8, 2025 02:01

bufdev mentioned this pull request Jun 8, 2025

Option to remove connect wrappers in generated code #848

Closed

jhump reviewed Jun 9, 2025

View reviewed changes

Merge

ccd966f

emcfarlane mentioned this pull request Jun 10, 2025

Add RecoverInterceptor as alternative to WithRecover #824

Open

This was referenced Jun 30, 2025

Implement CallInfo usage and update example and integration tests #855

Closed

Implement CallInfo usage in context and add integration tests #856

Merged

Steve Ayers and others added 2 commits July 24, 2025 17:07

Merge branch 'main' into simple

43f7df2

bufdev mentioned this pull request Aug 14, 2025

Standardize on For over From #867

Merged

Merge branch 'main' into simple

29b5ba1

bufdev commented Aug 14, 2025

View reviewed changes

s/From/For/

4587dc5

Signed-off-by: bufdev <bufdev-github@buf.build>

bufdev force-pushed the simple branch from 1438357 to 4587dc5 Compare August 14, 2025 15:23

bufdev commented Aug 14, 2025

View reviewed changes

Add better stream types for bidi (#869)

d86bde7

This adds better stream types for bidi streams, making them more consistent with client streaming. Signed-off-by: Steve Ayers <sayers@buf.build>

Merge branch 'main' into simple

cbf2da8

jhump approved these changes Aug 25, 2025

View reviewed changes

jhump mentioned this pull request Aug 25, 2025

Fix trailer propagation for gRPC errors connectrpc/vanguard-go#173

Merged

bufdev merged commit f2433b1 into main Aug 25, 2025
12 of 14 checks passed

bufdev deleted the simple branch August 25, 2025 20:42

glerchundi mentioned this pull request Aug 31, 2025

Generate a compatibility bridge for standard gRPC server implementations #874

Closed

emcfarlane mentioned this pull request Sep 24, 2025

Prepare for v1.19.0 #883

Merged

majst01 mentioned this pull request Oct 6, 2025

Consider connectrpc simple metal-stack/api#49

Closed

Conversation

bufdev commented Jun 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mfridman commented Jun 7, 2025

Uh oh!

Alfus commented Jun 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mattrobenolt commented Jun 8, 2025

Uh oh!

bufdev commented Jun 8, 2025

Uh oh!

bufdev commented Jun 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mattrobenolt commented Jun 8, 2025

Uh oh!

jhump left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jhump Jun 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bufdev commented Jun 9, 2025

Uh oh!

jhump commented Jun 9, 2025

Uh oh!

jhump commented Jun 9, 2025

Uh oh!

bufdev commented Jun 10, 2025

Uh oh!

pkwarren commented Jun 10, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bufdev commented Aug 18, 2025

Uh oh!

smaye81 commented Aug 19, 2025

Uh oh!

bufdev commented Aug 20, 2025

Uh oh!

jrinehart-buf commented Aug 20, 2025

Uh oh!

Uh oh!

staugaard commented Sep 18, 2025

Uh oh!

emcfarlane commented Sep 26, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

11 participants

bufdev commented Jun 7, 2025 •

edited

Loading

Alfus commented Jun 8, 2025 •

edited

Loading

bufdev commented Jun 8, 2025 •

edited

Loading

jhump Jun 9, 2025 •

edited

Loading