Skip to content
This repository has been archived by the owner on Mar 11, 2021. It is now read-only.

Merge crate abci-rs into abci #112

Closed
wants to merge 3 commits into from
Closed

Merge crate abci-rs into abci #112

wants to merge 3 commits into from

Conversation

devashishdxt
Copy link
Contributor

@devashishdxt devashishdxt commented Jan 10, 2020

Merge abci-rs into abci which uses latest async/await feature of Rust.

Fixes #115
Fixes #107
Fixes #105
Fixes #30

Copy link
Contributor

@tomtau tomtau left a 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

@devashishdxt
Copy link
Contributor Author

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 rust-abci traits can use current version. We can release this as a major version change (0.7.0) signifying non-backwards compatible changes.

@tomtau
Copy link
Contributor

tomtau commented Jan 10, 2020

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 rust-abci traits can use current version. We can release this as a major version change (0.7.0) signifying non-backwards compatible changes.

e.g. that there's a module next.rs (or any name) that exposes that functionality and can be enabled with some feature-flag. My preference for that is that there's a transitional period during which the old Rust abci server has some limited support before it's removed -- but if the consensus is for an immediate major version change switch, I'm fine with it

@tac0turtle
Copy link
Contributor

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

@tomtau
Copy link
Contributor

tomtau commented Jan 11, 2020

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

src/server.rs Outdated Show resolved Hide resolved
@devashishdxt
Copy link
Contributor Author

@marbar3778 Updated PR to work with Tendermint v0.33.0

@tac0turtle
Copy link
Contributor

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.

@devashishdxt
Copy link
Contributor Author

@marbar3778 I don’t have a Twitter account. You can link my GitHub account if you want. :)

Copy link
Contributor

@liamsi liamsi left a 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?

@devashishdxt devashishdxt requested review from liamsi and tomtau January 24, 2020 02:46
@devashishdxt
Copy link
Contributor Author

@marbar3778 @liamsi: Added changelog entry

Copy link
Contributor

@tomtau tomtau left a 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:

  1. 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

  2. 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

@tac0turtle
Copy link
Contributor

@tomtau @yihuang are there still any major concerns about this being too breaking?

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?

Copy link
Contributor

@tomtau tomtau left a 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)

README.md Outdated Show resolved Hide resolved
@devashishdxt
Copy link
Contributor Author

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 abci-rs crate into this one. Extra documentation for upgrading existing code can be done in a different PR.

@tac0turtle
Copy link
Contributor

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.

@tomtau
Copy link
Contributor

tomtau commented Feb 8, 2020

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

src/server.rs Outdated Show resolved Hide resolved
@devashishdxt devashishdxt requested a review from tomtau February 28, 2020 03:42
Copy link
Contributor

@tomtau tomtau left a 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

@devashishdxt
Copy link
Contributor Author

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.

@devashishdxt devashishdxt requested a review from tomtau March 4, 2020 03:11
@devashishdxt
Copy link
Contributor Author

Closing this PR. Will submit one without any merge issues in future.

@devashishdxt devashishdxt deleted the abci-rs branch March 4, 2020 03:32
Copy link
Contributor

@tomtau tomtau left a 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

Comment on lines +233 to +234
int64 max_age_num_blocks = 1;
google.protobuf.Duration max_age_duration = 2 [(gogoproto.nullable)=false, (gogoproto.stdduration)=true];
Copy link
Contributor

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?

Comment on lines +1 to +2
#[cfg(unix)]
use std::path::PathBuf;
Copy link
Contributor

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)]
Copy link
Contributor

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?

@ruseinov
Copy link

@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.

@devashishdxt
Copy link
Contributor Author

@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 abci-rs(Documentation) and suggest some improvements that you feel should be included in this crate. The final API design will not be much different from abci-rs. So, it'll be very straight forward to switch when updated version of this crate is available.

@ruseinov
Copy link

ruseinov commented Apr 1, 2020

@devashishdxt that makes sense, I will look into this as soon as I start implementing the abci app.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
7 participants