-
Notifications
You must be signed in to change notification settings - Fork 34
Conversation
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'd prefer this to be done in a non-breaking / less drastic way, e.g.:
- abci-rs functionality is exposed under an optional module
- the existing rust-abci trait functionality is still there, but marked as deprecated
What do you mean by optional module? Also, people who want to use existing |
e.g. that there's a module |
I was thinking if this is such a breaking change could it wait for Tendermint 0.33 ( i am working on finalizing it) and then this will start with support for the new version, as it holds many breaking changes. Is this needed for users that are currently on the 0.32 series |
the new code adds, for example, the communication over unix domain sockets... so not needed, but good to have |
@marbar3778 Updated PR to work with Tendermint v0.33.0 |
could a changelog entry be added with a short synopsis of the changes? also if you have a twitter we'd love to give you a shoutout for this work. |
@marbar3778 I don’t have a Twitter account. You can link my GitHub account if you want. :) |
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.
Great work! Very clean and well done PR. I was wondering how extensive this was tested? Agree with @marbar3778 that a proper changelog entry would be awesome!
@tomtau @yihuang are there still any major concerns about this being too breaking?
@marbar3778 @liamsi: Added changelog entry |
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.
@tomtau @yihuang are there still any major concerns about this being too breaking?
0.33 is breaking anyway, so it could be together.
I was wondering how extensive this was tested?
It seems there are no tests -- it'd be good to add some before this is merged:
-
it removed tests that were added to capture this earlier bug: Panic on too many/large transactions #20 -- even though this has been fixed, it doesn't hurt to keep the tests
-
may be good to add tests / properties capturing some of the desired properties of this new implementation (if the old implementation wasn't removed, but deprecated, there could have been some temporary tests, testing that given the same input, they produce the same output):
- for any valid sequence of abci messages, consensus state should be valid
- query/mempool messages should be processed irrespective of consensus connection
- ...
For the second property, I guess this could be simulated with some "dummy" abci app where some of the consensus connection response handling code (e.g. DeliverTx or begin block) are artificially expensive or non-terminating, so that they block and one can check that the query/mempool is still processed
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.
0.33 is breaking anyway, so it could be together.
we could cut the 0.7 release with 0.33 tendermint then merge this PR and cut 0.8 if people would like to maintain the old functionality for a bit longer?
I think either option is fine -- can one get any downstream insights / statistics from dependabot, so that we can get some idea of the impact or ask for more opinions?
Besides tests, one other thing missing in this PR would be a very short "porting old abci applications" section / paragraph guide -- it seems it should be fairly straightforward, but still would be good to briefly document that (so one can get a quick idea of the required effort before jumping into it: new dependencies, separating out shared state, extra keywords, broken down application... currently, one would need to deduce that from reading the counter example)
This PR is for merging |
How do people feel about merging this and having a follow-up PR for docs and anything else? We should just make issues with what we want in the follow-up PRs. |
maybe ok to merge to develop, but not ok to release (merge to master) before at least a few tests are in place |
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.
TM v0.33 support was just released under 0.7 -- so there are some merge conflicts, so it'll be good to resolve those + bump to v0.8
Resolved all the merge conflicts. |
Closing this PR. Will submit one without any merge issues in future. |
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.
went through the changes in detail -- ok to merge to develop, but shouldn't be released / merged to master yet -- the biggest concern was put into an issue: #119
before merging it, it'll be good to rebase these changes on top of the latest develop, because at least Github UI diff shows some weird parts, so want to do a final double check what will actually end up there.
Other comments (can be addressed in a different PR):
-
sanity-check-validation of a consensus state machine is a kind of a random change / feature sneaked in here (not even mentioned in the changelog) that's orthogonal to the rest and will need more work -- e.g. since this is a dynamic check, instead of a static check (as originally envisioned with session types), it could also check other invariants (e.g. about block height, time, ...)
-
unix socket can be there as a default feature -- just distinguish those two connections based on the prefix in the connection string, similarly to Tendermint or KMS configurations
-
not sure why there are 100s of lines of code for these duplicate wrapper ABCI types that don't seem to do anything, but contain the same information as the protobuf types without some protobuf fluff? It'd be preferable to just use the protobuf types. If there's some strong reason for them, it'll be good to see whether the same can be achieved with some extra protobuf codegen configuration or if there can be a macro that will simplify this
int64 max_age_num_blocks = 1; | ||
google.protobuf.Duration max_age_duration = 2 [(gogoproto.nullable)=false, (gogoproto.stdduration)=true]; |
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'm a bit puzzled why this diff shows up when it's like that on develop: https://github.com/tendermint/rust-abci/blob/develop/protobuf/abci/types/types.proto#L227
can you perhaps rebase on the latest develop?
#[cfg(unix)] | ||
use std::path::PathBuf; |
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.
as the whole thing is breaking, perhaps this doesn't need to be feature guarded and TCP vs IPC can have a prefix, just like in Tendermint configurations?
use crate::proto::abci::{Event as ProtoEvent, RequestBeginBlock, ResponseBeginBlock}; | ||
use crate::types::{Event, Evidence, Header, LastCommitInfo}; | ||
|
||
#[derive(Debug, Default)] |
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.
Not sure what the point of these wrapper types is -- why not just use the protobuf types?
@devashishdxt Hello Devashish, I'm curious if there's a plan to revive this work anytime soon. The reason I'm asking is that I'm likely to go forward and implement an abci app in Rust. I used to be one of the developers https://github.com/iov-one/weave so looking into implementing something of sorts for Rust, a framework that would allow for custom routing/handling/middlewares. |
Hi @ruseinov, I'm a bit busy with other things right now. I'll start working on this as soon as I have some free time. We still need to reach a consensus for some unresolved things (see comments above). In the meantime, you can try using |
@devashishdxt that makes sense, I will look into this as soon as I start implementing the abci app. |
Merge
abci-rs
intoabci
which uses latestasync
/await
feature of Rust.Fixes #115
Fixes #107
Fixes #105
Fixes #30