[Bug] BSR Remote Go Generation does not support "go_package" option

[ivan-elude]

Hey team,

We are prototyping using the BSR with remote Go code generation for our code base. Initial setup has been successful, but it seems that the option go_package is not being respected.

Our proto files have option go_package = "./;gen"; set, which dumps all of our protos into the gen workspace, which is mapped to a util library. So, all of our other code can simply import pb "company.tld/util/gen" and then use gen.* for all proto purposes.

When using the BSR, the package names are getting generated based on the folder structure.

protos
└── foo
    ├── proto1.proto
└── bar
    ├── proto2.proto

yields individual protos such as foo.Proto1 and bar.Proto2, which causes import cycle errors in golang.

If possible, we believe the BSR should respect the go_package option when generating go files for consumption.

[amckinney]

How are you generating your code? Are you using local generation (i.e. via a buf.gen.yaml) with Managed Mode? Managed Mode is designed to overwrite the go_package option, so that would explain why you're seeing this behavior.

If you're using Buf's Go module proxy, then this is working as expected - the go_package value must be overwritten so that all of the code you generate adopts the BSR's Go module proxy base path (e.g. go.buf.build/...).

---

Depending on what you're trying to do we can give different guidance (e.g. local generation with a remote BSR module, such as buf generate buf.build/acme/petapis). Or using a combination of both with Managed Mode that refers to go.buf.build/... paths, like this example.

[ivan-elude]

Hey @amckinney , thanks for the quick note!

Right now, we are running local generation with the buf.gen.yaml, and it works great. One of the reasons we are exploring a move to Managed mode is our CI fails out 50% of the time due to Failure: context deadline exceeded, as well as Failure: internal error, contact support, reference code: c40e5b, which we traced back to too many requests getting sent to buf.build.

For (1) - If we use something like buf generate buf.build/acme/petapis, I'm guessing we'd have the same API rate limits?

For (2) - is there a way to do this with wildcard options? We have 86 proto files, so manually keeping them in sync would be a bit tedious.

[amckinney]

Have you still be experiencing those failures in CI/CD? We've tackled a couple of issues in the last couple weeks, so hopefully those failures have calmed down - please let us know otherwise.

1. In general, yes you'd hit the same API rate limits on the BSR as a whole. However, you wouldn't be relying on remote generation at all (you would just be building an image from a remote module), so you might encounter less (or more) internal errors.

2. Unfortunately no, there isn't a way to do this with wildcard options today. That does sound tedious though - ideally you'd just be able to use remote generation wholesale and you wouldn't need to use the go_package override workaround in the example I linked.

I'm going to close this issue as-is because we won't be changing the BSR's behavior w.r.t overriding the go_package option (i.e. what the issue is originally about). But feel free to continue commenting here if you need more guidance with respect to your setup in particular.

[ivan-elude]

Hi @amckinney , thanks for the information! We'll keep experimenting and post an update here once some more data rolls in.