Skip to content
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

Finish Ethereum and Dummy adapter #143

Merged
merged 25 commits into from
Oct 9, 2019

Conversation

samparsky
Copy link
Contributor

@samparsky samparsky marked this pull request as ready for review September 20, 2019 14:26
@@ -0,0 +1 @@
[{"constant":true,"inputs":[{"name":"","type":"bytes32"}],"name":"withdrawn","outputs":[{"name":"","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[{"name":"","type":"bytes32"},{"name":"","type":"address"}],"name":"withdrawnPerUser","outputs":[{"name":"","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[{"components":[{"name":"creator","type":"address"},{"name":"tokenAddr","type":"address"},{"name":"tokenAmount","type":"uint256"},{"name":"validUntil","type":"uint256"},{"name":"validators","type":"address[]"},{"name":"spec","type":"bytes32"}],"name":"channel","type":"tuple"}],"name":"channelOpen","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":false,"inputs":[{"components":[{"name":"creator","type":"address"},{"name":"tokenAddr","type":"address"},{"name":"tokenAmount","type":"uint256"},{"name":"validUntil","type":"uint256"},{"name":"validators","type":"address[]"},{"name":"spec","type":"bytes32"}],"name":"channel","type":"tuple"},{"name":"stateRoot","type":"bytes32"},{"name":"signatures","type":"bytes32[3][]"},{"name":"proof","type":"bytes32[]"},{"name":"amountInTree","type":"uint256"}],"name":"channelWithdraw","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":false,"inputs":[{"components":[{"name":"creator","type":"address"},{"name":"tokenAddr","type":"address"},{"name":"tokenAmount","type":"uint256"},{"name":"validUntil","type":"uint256"},{"name":"validators","type":"address[]"},{"name":"spec","type":"bytes32"}],"name":"channel","type":"tuple"}],"name":"channelWithdrawExpired","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":true,"inputs":[{"name":"","type":"bytes32"}],"name":"states","outputs":[{"name":"","type":"uint8"}],"payable":false,"stateMutability":"view","type":"function"},{"anonymous":false,"inputs":[{"indexed":true,"name":"channelId","type":"bytes32"}],"name":"LogChannelOpen","type":"event"},{"anonymous":false,"inputs":[{"indexed":true,"name":"channelId","type":"bytes32"},{"indexed":false,"name":"amount","type":"uint256"}],"name":"LogChannelWithdrawExpired","type":"event"},{"anonymous":false,"inputs":[{"indexed":true,"name":"channelId","type":"bytes32"},{"indexed":false,"name":"amount","type":"uint256"}],"name":"LogChannelWithdraw","type":"event"}]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can't you include adex-protocol-eth as a submodule?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have included it

@@ -1,7 +1,7 @@
#![deny(clippy::all)]
#![deny(rust_2018_idioms)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this needed?

Copy link
Member

@elpiel elpiel Sep 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rust-lang/rust#52047
Some good lints for the 2018 edition

// @TODO
Ok("hello".to_string())
fn session_from_token(&mut self, token: &str) -> AdapterResult<Session> {
let mut identity = "";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you should use a functional style here
let identity = self.tokens_for_auth.iter().find(|(key, val)| val == token)


match who {
Some((id, _)) => {
let auth = self.tokens_for_auth.get(&id).unwrap();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this unwrap should be expect so that you can explain why you make that assumption

None,
&Some(self.keystore_pwd.clone()),
)
.expect("Failed to create account");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why doesn't this just return an Err?

public_to_address(
&wallet
.public(&self.keystore_pwd)
.expect("failed to get public key")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same...err handling should use Err

contract_address,
include_bytes!("../contract/Identity.json"),
)
.unwrap();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is OK to be unwrapped, but you should use lazy_static for this


let contract_query =
contract.query("privileges", verified.from, None, Options::default(), None);
let priviledge_level: U256 = contract_query.wait().unwrap();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's keep this like that for now
but we should change this to an async call ASAP

(None, Some(wallet)) => {
let payload = Payload {
id: validator.id.clone(),
era: usize::try_from(Utc::now().timestamp()).expect("failed to parse utc now"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is an actual OK case for expect! cause there's no realistic way it can fail

);

// Sign
let expected_response =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

those match with the JS impl, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes it does

@samparsky samparsky force-pushed the ethereum-adapter branch 3 times, most recently from 7aaa0c5 to 11b1355 Compare September 27, 2019 11:55
@@ -64,28 +67,55 @@ pub struct EthereumChannel {
pub creator: String,
pub token_addr: String,
pub token_amount: String,
pub valid_until: String,
pub valid_until: i64,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this milliseconds (can we document this)? Should we try to use DateTime?

Copy link
Contributor Author

@samparsky samparsky Oct 1, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i64 works fine but the param to new requires Datetime

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I mean it's more about documenting it, creating the EthereumChannel requires Datetime, but when you use the public field valid_until from an object, you don't know where it comes from and what it is.

@samparsky
Copy link
Contributor Author

@elpiel The suggested changes have been made

elpiel
elpiel previously approved these changes Oct 1, 2019
@elpiel elpiel requested a review from Ivshti October 1, 2019 11:40
Ivshti
Ivshti previously approved these changes Oct 3, 2019
@samparsky samparsky dismissed stale reviews from Ivshti and elpiel via a781eb4 October 4, 2019 10:02
Comment on lines 163 to 172
let whoami = adapter.whoami();

let validator = self
.channel
.spec
.validators
.into_iter()
.find(|&v| v.id == whoami);
let auth_token = self
.adapter
.get_auth(validator.unwrap())
.expect("Failed to get user auth token");

let auth_token = adapter.get_auth(validator.unwrap());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even though we have fairly small amount of code, I see the confusion that leads to duplicating code by accident.

Here is what I don't understand: Why do we even bother to do this check, if we already have it in the initialization of the SentryInterface?
Why search for the adapter.whoami() in the channle.spec.validators and then even validator.unwrap() the value?
This whole thing can be simplified to just:

let auth_token = adapter.get_auth(adapter.whoami());

If you follow the implementation, the adapter.whoami() will always be included in the Channel validators, but it's just not obvious.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

adapter.whoami() returns a string,
.find(|&v| v.id == whoami); returns a ValidatorDesc

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, the idea behind the unwrap() is because we already check it in new() so it would always be there

.expect("Failed to get user auth token");

let auth_token = adapter.get_auth(validator.unwrap());
if let Err(e) = auth_token {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@samparsky samparsky requested review from Ivshti and elpiel October 4, 2019 15:12
@samparsky samparsky force-pushed the ethereum-adapter branch 2 times, most recently from 0a58df2 to cf785d4 Compare October 4, 2019 15:30
elpiel
elpiel previously approved these changes Oct 7, 2019
@elpiel elpiel mentioned this pull request Oct 9, 2019
@samparsky samparsky merged commit 6652af3 into AmbireTech:dev Oct 9, 2019
This was referenced Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants