Conversation
.is_document_key_store_response_required() | ||
.call(*server_key_id, key_server.clone(), &do_call) | ||
.unwrap_or(true) | ||
let (encoded, decoder) = service::functions::is_server_key_generation_response_required::call(*server_key_id, *key_server); |
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.
is_server_key_generation_response_required
-> is_document_key_store_response_required
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.
It is a little worrying that the tests still passed with the wrong function call. :/
|
@@ -81,15 +81,13 @@ impl Into<trace::RewardType> for RewardKind { | |||
#[derive(PartialEq, Debug)] | |||
pub struct BlockRewardContract { | |||
kind: SystemOrCodeCallKind, | |||
block_reward_contract: block_reward_contract::BlockReward, | |||
} |
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.
There's not a lot left of the BlockRewardContract
type. Not sure what would be better; can it become an enum
perhaps?
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 to do it in a separate pr. It seems to be a trivial, but a relatively big change
hash-fetch/src/urlhint.rs
Outdated
@@ -109,7 +108,6 @@ impl URLHintContract { | |||
/// Creates new `URLHintContract` | |||
pub fn new(client: Arc<RegistrarClient<Call=Asynchronous>>) -> Self { |
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.
indentation is off here
I am way too unfamiliar with the this code to be able to say something intelligent about it. As a general comment it seems like the new interface is slightly less ergonomic than the old (I believe the change was dictated by performance reasons though, so that's fine). |
tbh, I don't see how tying it to a struct could is any different than calling a freestanding method
if the signatures of contract functions are the same, nothing bad would happen cause the result of such encoding would be the same. but I guess you wanted to ask about calling two functions that have the accept params of the same type. well... there is not much we can do to prevent it... we just need to write appropriate tests for it |
Fair enough. |
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.
lgtm
this pull request updates the repo to use the latest version of ethabi.
@svyatonik please carefully review changes in secret store as they were the most complicated :)