Yellowstone proto version mismatch

Root causes

Ranked by frequency. First cause is the one to check first.

1. 01Provider upgraded the yellowstone-grpc-proto to add `BlockMeta` or `Entry` message types and your client is on an older proto.
2. 02You mixed clients — one part of your app uses v2 proto, another uses v3, and they share a connection.
3. 03Your build cached an old proto file and the new one didn't get re-generated.

Fix steps

1. 1

   Pin to the provider's proto version

   Most providers list their current supported proto version in docs. Subglow is on yellowstone-grpc-proto v3.0+. Pin `@triton-one/yellowstone-grpc` to a compatible version in package.json.

2. 2

   Regenerate proto bindings

   Delete `node_modules` and rebuild. For Rust, `cargo clean -p yellowstone-grpc-proto && cargo build`. For Python, delete the generated `*_pb2.py` files and re-run the protoc compiler.

3. 3

   Set up CI proto verification

   Add a step that pulls the provider's proto from GitHub and diffs against your vendored copy. Catches proto-drift before prod.

Related errors

• INVALID_ARGUMENT — bad subscribe filter
  `Status { code: InvalidArgument }` is the server rejecting your SubscribeRequest before streaming starts. Almost always a malformed filter: base58-encoded where base64 expected, commitment level spelled wrong, or an empty filter group.
• CANCELLED — stream closed unexpectedly
  `Status { code: Cancelled }` on an active stream almost always means the TCP connection was closed by a middlebox (Kubernetes pod restart, load balancer, NAT timeout). It's not an error in the programmer sense — it's a normal event to handle with reconnect logic.