gRPC Service Rollback and Protobuf Schema Compatibility Boundary

Our team must decide whether rolling back a gRPC service to a previous protobuf schema is safe when clients and servers may not be updated simultaneously. Because gRPC does not automatically version services, compatibility depends entirely on protobuf field-number and type rules under standard protobuf semantics. We know that adding a new optional field with a unique number is safe, but removing a field, reusing its number, or changing an existing field type can cause deserialization failures on peers still using the old schema.

The uncertainty is whether our rollback plan can tolerate mixed-version traffic. Some clients may lag behind the new schema, and custom options or google.protobuf.Any fields may obscure standard compatibility guarantees. We need a clear boundary for when rollback is acceptable and when it requires coordinated client and server updates.

What specific protobuf schema changes make a gRPC service rollback unsafe under mixed client-server versions? How should we evaluate rollback safety when custom options or Any fields are present? Is there a documented gRPC behavior that enforces schema compatibility, or is it entirely the integrator's responsibility?