-
Notifications
You must be signed in to change notification settings - Fork 228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tendermint RPC 0.34 compatibility API #1143
Conversation
Start on the tendermint 0.34 legacy support, gated by "tendermint-0.34" feature.
The most naive copy of the implementation, swapping out Event and Subscription* for their v0_34 counterparts.
This will be the basis for core reuse between WebSocketClient for different protocol versions.
Share all subscription management code between the two WebSocketClient implementations by making it generic about the event type.
Test the parsing of v0_34::event::Event in the kvstore_fixtures tests, and tell the v0_34::WebSocketClient test to load the v0.34 fixtures.
865661a
to
781dbfa
Compare
Codecov Report
@@ Coverage Diff @@
## master #1143 +/- ##
========================================
+ Coverage 64.7% 65.0% +0.2%
========================================
Files 232 238 +6
Lines 15667 16046 +379
========================================
+ Hits 10142 10432 +290
- Misses 5525 5614 +89
Continue to review full report at Codecov.
|
Unbreaks the wasm build.
The encoding of the hash field in the request has changed, so we need to use a legacy endpoint struct.
The websocket client is properly enabled by the "websocket-client", feature, in addition to the whole v0_34 module enabled by the "tendermint-0.34" feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, this seems like a substantial amount of work @mzabaluev, thanks so much! I didn't realize we'd need to make the client machinery generic over the data structures that differ between Tendermint versions, but it totally makes sense.
Two questions, and it'd be great to also have a changelog entry for this, but otherwise LGTM 👍
/// A client that exclusively provides [`Event`] subscription capabilities, | ||
/// without any other RPC method support. | ||
#[async_trait] | ||
pub trait SubscriptionClient { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of the benefits of this approach here is that the API can evolve across different versions of Tendermint, but one of the drawbacks is that callers need to refer to Tendermint version-specific client traits.
An alternative approach here would be to have one SubscriptionClient
trait for all supported versions of Tendermint, and have it be generic over the Event
type produced by the subscription client. Then the caller could also be generic over the event type. I'd be interested to know whether you considered and ruled out such an approach? (I haven't actually done the hard work here, so I'm not aware yet of the ripple effects throughout the codebase of such an approach.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's possible to introduce Subscription
and/or Event
as associated types for the unified SubscriptionClient
trait, but I was not sure if the more substantial API change is desirable. Currently, v0_34
can be treated like a bolt-on with no complications to the definitions elsewhere. In the relayer, we'll have to explicitly specialize for both event types anyway, because parsing for old subscription events has to be different (it is a good thing to have this changed for 0.35).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense 👍 I'd say we should keep your changes as-is then, and we can always look at merging the traits at some point in a future version of tendermint-rs if necessary.
Renamed from "tendermint-0.34" to "v0_34", to mirror the name of the top-level module.
In a meeting with folks from the Tendermint team at Interchain, it has been suggested that we don't need to expose the pre-0.35 event data structure and its separate subscription stream API, what we can instead do is transform the "flattened" key-value map into a list of ABCI events using the knowledge of how Tendermint 0.34 nodes encode event types and tags into the flattened map. With this, there are fewer reasons to provide a statically different
|
I'm closing this for now due to lack of urgent need for this change (given non-adoption of Tendermint 0.35 in the upcoming release of Cosmos SDK) and the alternative idea of transforming the pre-0.35 RPC subscription event data into the uniform current API. |
Add a feature-gated
v0_34
module in the tendermint-rpc crate, providing compatibility with Tendermint nodes using the RPC protocol as implemented in Tendermint Go version 0.34.The
v0_34
module provides APIs that exhibit the protocol differences, mainly due to the changes in the subscription event data structure:Event
Subscription
SubscriptionClient
WebSocketClient
.changelog/