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

Fixed block ref param handling in eth_call #2278

Merged
merged 1 commit into from Apr 8, 2024

Conversation

Vovchyk
Copy link
Contributor

@Vovchyk Vovchyk commented Mar 28, 2024

Description

Motivation and Context

How Has This Been Tested?

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • Tests for the changes have been added (for bug fixes / features)
  • Requires Activation Code (Hard Fork)
  • Other information:

fmacleal
fmacleal previously approved these changes Apr 1, 2024
Copy link
Contributor

@fmacleal fmacleal left a comment

Choose a reason for hiding this comment

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

LGTM

@@ -47,8 +47,11 @@ default String eth_sign(HexAddressParam addr, HexDataParam data) {
return getEthModule().sign(addr.getAddress().toHexString(), data.getAsHexString());
}

default String eth_call(CallArgumentsParam args, BlockIdentifierParam bnOrId) {
return getEthModule().call(args, bnOrId);
default String eth_call(CallArgumentsParam args, BlockRefParam blockRefParam) {
Copy link
Contributor

Choose a reason for hiding this comment

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

As we are updating this method, is there a reason to implement this logic into the interface using default? our could we move the method implementation to the implementation class?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the idea was to make it as minimalistic as possible. But yeah, in future we may want to refactor this a bit and move all implementations of default methods to appropriate impl classes

Copy link

sonarcloud bot commented Apr 8, 2024

@Vovchyk Vovchyk merged commit b0d2515 into master Apr 8, 2024
10 checks passed
@Vovchyk Vovchyk deleted the eth-call-block-ref-param-fix branch April 8, 2024 08:44
@aeidelman aeidelman added this to the Arrowhead 6.1.0 milestone Apr 8, 2024
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.

None yet

4 participants