examples/bsr-quickstart: checked-in generated code no longer builds against the in-tree runtime

[iainmcgin]

examples/bsr-quickstart pins the remote plugin buf.build/anthropics/buffa:v0.5.2 in buf.gen.yaml but builds against the in-tree buffa runtime via a path dependency, and the checked-in src/gen/example.v1.rs (hand-patched in #184, #284 and #409 since it was generated) no longer compiles against it. On main (1f5d80e, v0.9.2), cargo check in that directory fails with four errors:

error[E0046]: not all trait items implemented, missing: `merge_view_field`
   --> src/gen/example.v1.rs:814:9
error[E0599]: no method named `_merge_into_view` found for mutable reference `&mut TimestampView<'a>`
   --> src/gen/example.v1.rs:734:60
error[E0599]: no associated item named `_decode_ctx` found for struct `TimestampView<'a>`
   --> src/gen/example.v1.rs:737:104
error[E0308]: mismatched types  (`to_owned_message` now infallible on `OwnedView`)
    --> src/gen/example.v1.rs:1141:17

The example is in the workspace exclude list, so no CI job builds it and the drift went unnoticed across 0.7 → 0.9.

Two ways to fix, either is fine:

1. Bump the pin to the newest published BSR plugin and re-run task gen-bsr-quickstart-example, then repeat at each release (the buf.gen.yaml comment already says to). This keeps the example honest about what a BSR user gets, but it can only ever track the published plugin, so it will lag main between releases.
2. Switch the example's Cargo.toml back to the crates.io buffa/buffa-types at the version matching the pinned plugin (the commented-out lines are already there), so plugin output and runtime always agree, and add a cheap CI step that runs cargo check in the directory.

Option 2 plus a release-checklist line to bump both pins together seems the more durable of the two.

[harshitwandhare]

Reproduced on 18476fa, so it is still current. Same four errors, same lines.

Option 2 does not work as written. I swapped the two path deps for crates.io =0.5.2, matching the pinned plugin, and checked it. It fails differently:

error[E0433]: cannot find `unsafe_impl_view_lifetime_parametric` in `buffa`
error[E0433]: cannot find `DecodeContext` in `buffa`
error[E0407]: method `decode_view_with_ctx` is not a member of trait `::buffa::MessageView`
error: the compiler unexpectedly panicked. This is a bug

The ICE is incidental, rustc 1.95.0 rendering one of the three.

The checked-in example.v1.rs is no longer v0.5.2 plugin output, so pinning the runtime to the plugin's version does not make the two agree. It has been hand-patched four times since it was generated in #116, not the three listed above: #381 added ::buffa::unsafe_impl_view_lifetime_parametric!(GreetingView); on 2026-09-08, two days after you filed this.

That is also why the drift stays quiet. The Cargo.toml comment calls the example a forward-compat canary, but each in-tree change that breaks it gets absorbed by patching the generated file, so the canary never fires and the file drifts further from what any plugin emits.

Current codegen output is clean. Regenerating with the in-tree protoc-gen-buffa at the same opts (file_per_package=true,json=true,views=true) against the in-tree runtime:

cargo check                                clean
cargo run                                  expected encode / view / JSON output
cargo clippy --all-targets -- -D warnings  clean

That output is 1168 lines against the checked-in 1282, so the difference is accumulated patching.

So both options need a regen, and option 2 is a regen plus the Cargo.toml swap rather than the swap alone. With that included I agree option 2 is the more durable, for the reason you gave.

What I could not check: no buf or BSR access here, so I could not produce published-plugin output or see which plugin versions exist past v0.5.2. The above uses the in-tree plugin, which stands in for the published one rather than being the same artifact.

Happy to send option 2 if you tell me which version to land on: =0.5.2 to match the current pin, or both pins bumped to the newest published plugin. The CI cargo check step is the cheap half either way.

[harshitwandhare]

Installed buf, which answers the version question I asked above, and one of the two options turns out not to be available.

v0.9.2 is published, so the pin can match the current release rather than 0.5.x. Probing the BSR: v0.5.2, v0.6.0, v0.7.1, v0.8.0, v0.8.1, v0.9.0, v0.9.1 and v0.9.2 all resolve.

Option 1 does not compile today. With the pin at v0.9.2 and the path dependencies kept, published output against main gives four of

error[E0277]: `GreetingView<'_>` does not implement `ViewLifetimeParametric`

because #381 requires the marker and no published plugin emits it. That is the case #381's own description already calls out. The published v0.9.2 output and the in-tree protoc-gen-buffa differ by exactly that one line, so the plugin is otherwise current.

So I sent option 2 as #436: pin v0.9.2, regenerate from it, and move buffa / buffa-types to the matching crates.io release. It also drops the "cannot be regenerated until a 0.10 BSR plugin is published" constraint, since the example stops tracking main.

cargo check, cargo run and clippy --all-targets -D warnings are clean on it. The regenerated src/gen/ is identical under either option, so switching to option 1 later is two lines in Cargo.toml.