examples: pin bsr-quickstart to one buffa release and check it in CI

[harshitwandhare]

examples/bsr-quickstart pinned the BSR plugin at v0.5.2 but compiled against the in-tree runtime through path dependencies, and the checked-in src/gen/example.v1.rs matched neither. Four errors on 18476fa, as reported.

That file had been hand-patched four times since it was generated (#184, #284, #409, #381) rather than regenerated, so it tracked the in-tree API by hand while still being described as published-plugin output. The directory sits in the workspace exclude list, so nothing compiled it and each round of drift stayed invisible.

Neither half of the fix works alone.

Pinning the runtime back to crates.io =0.5.2 to match the plugin fails with a different three errors, because the file is no longer v0.5.2 output:

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`

Bumping only the plugin pin fails too. v0.9.2 is published, but #381 requires the ViewLifetimeParametric marker and no published plugin emits it yet, so published v0.9.2 output against main gives four of

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

which is the situation #381's own description calls out as needing a 0.10 BSR plugin.

So the plugin pin moves to v0.9.2, src/gen/ is regenerated from it, and buffa / buffa-types move to the matching crates.io release. Both halves come from one buffa version, which is also what a downstream BSR user has, and the example stops depending on main. That is what clears the "cannot be regenerated until a 0.10 BSR plugin is published" blocker: the example no longer needs to track main, so a 0.10 plugin is only wanted when the example should start demonstrating 0.10.

The unsafe_impl_view_lifetime_parametric! line added by hand in #381 goes away with the regen, which is correct here: buffa 0.9.2 has no such macro, and the example no longer compiles against the runtime that requires it.

The cost is the forward-compat canary the old Cargo.toml comment described, and it was not working. The published plugin lags main by design, so between releases the canary's only outcome was a red example, and it was being silenced by hand-patching rather than acted on. In-tree codegen against the in-tree runtime is already covered by buffa-test and the two codegen compile matrices in lint-and-test.

A cargo check step in lint-and-test now covers the example. With both pins naming one release it can only go red if one pin moves without the other, which is what the release bump has to get right anyway.

Verified

Regenerated with buf generate against the pinned v0.9.2 plugin, then in examples/bsr-quickstart:

cargo check                                clean
cargo run                                  encodes 47 bytes, prints the views and the JSON
cargo clippy --all-targets -- -D warnings  clean

Cross-check on the regen: published v0.9.2 plugin output and the in-tree protoc-gen-buffa differ by exactly the one unsafe_impl_view_lifetime_parametric!(GreetingView); line, so the published plugin is otherwise current with in-tree codegen.

Not run: the workspace test suite, since nothing here touches a workspace crate. The ci.yml step is the only change outside examples/bsr-quickstart and .changes/.

This is option 2 from the issue. If you would rather have option 1, the regenerated src/gen/ is the same file either way and only the two Cargo.toml lines change, but it does not compile against main today for the #381 reason above.

Fixes #427.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[iainmcgin]

[claude code] Thanks for this, and for the investigation on #427. It showed that option 2 needed a regen as well as the Cargo.toml swap, and that option 1 can't compile against main until a 0.10 plugin ships.

Checked on this head:

• src/gen/example.v1.rs is byte-identical to a fresh buf generate against buf.build/anthropics/buffa:v0.9.2.
• cargo check --locked, cargo clippy --all-targets -- -D warnings and cargo run are clean in examples/bsr-quickstart.
• lint-and-test passed with the new step on the previous head.

I pushed one commit on top:

• --locked on the CI step. serde, serde_json and the transitive deps float. Without it, a new upstream release could turn lint-and-test red on unrelated PRs, and a stale Cargo.lock after a pin bump would pass CI.
• The bump procedure, where the person bumping will read it. The gen-bsr-quickstart-example task description told you to bump only the plugin pin, which would now break the new check. It and a new note in CONTRIBUTING.md's checked-in generated code section now say to bump the plugin pin and the crate versions together once the release's BSR plugin is published.
• A stale Taskfile comment. The comment above build-examples said every example uses path deps.
• Shorter comments. The Cargo.toml, buf.gen.yaml and ci.yml comments now give only the reasoning that stays true, and the history is left to examples/bsr-quickstart: checked-in generated code no longer builds against the in-tree runtime #427 and this PR. The Cargo.toml comment also notes that a downstream project wants version = "0.9", not an exact = pin.
• The changelog fragment no longer mentions CI in its headline.

I kept the exact =0.9.2 pins, since they make the plugin/runtime coupling visible in the manifest.

[iainmcgin]

[claude code] Approving with the fixups above; CI re-approved on f00018d.