Test Results

 21 files   -  1  275 suites  +4   55m 49s ⏱️ - 9m 54s
614 tests + 5  597 ✅ + 5  4 💤 +1  13 ❌  - 1 
819 runs   - 27  797 ✅  - 27  4 💤 ±0  18 ❌ ±0 

For more details on these failures, see this check.

Results for commit 94e77f6. ± Comparison against base commit 373f1dc.

"before all" hook for "should execute "eth_getCode" for hts token" ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-2 RPC Server Acceptance Tests eth_getCode "before all" hook for "should execute "eth_getCode" for hts token"
"before all" hook in "@api-batch-2 RPC Server Acceptance Tests" ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-2 RPC Server Acceptance Tests "before all" hook in "@api-batch-2 RPC Server Acceptance Tests"
"before each" hook for "from/to Addresses when transferring HTS tokens to the tokenAddress are in evm and long-zero format" ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-2 RPC Server Acceptance Tests "before each" hook for "from/to Addresses when transferring HTS tokens to the tokenAddress are in evm and long-zero format"

@release should execute "eth_getCode" for contract evm_address ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-2 RPC Server Acceptance Tests eth_getCode @release should execute "eth_getCode" for contract evm_address
@release should execute "eth_getCode" for contract with id converted to evm_address ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-2 RPC Server Acceptance Tests eth_getCode @release should execute "eth_getCode" for contract with id converted to evm_address
should execute "eth_getBlockByNumber", hydrated transactions = true for a block that contains a call with CONTRACT_NEGATIVE_VALUE status ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests Block related RPC calls should execute "eth_getBlockByNumber", hydrated transactions = true for a block that contains a call with CONTRACT_NEGATIVE_VALUE status
should execute "eth_getCode" for hts token ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-2 RPC Server Acceptance Tests eth_getCode should execute "eth_getCode" for hts token
should not return contract bytecode after sefldestruct ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-2 RPC Server Acceptance Tests eth_getCode should not return contract bytecode after sefldestruct
should return 0x0 for account alias on eth_getCode ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-2 RPC Server Acceptance Tests eth_getCode should return 0x0 for account alias on eth_getCode
should return 0x0 for account evm_address on eth_getCode ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-2 RPC Server Acceptance Tests eth_getCode should return 0x0 for account evm_address on eth_getCode
should return 0x0 for non-existing contract on eth_getCode ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-2 RPC Server Acceptance Tests eth_getCode should return 0x0 for non-existing contract on eth_getCode

♻️ This comment has been updated with latest results.

Great work overall. Blocking as one warning needed to be addressed.

Also, is it feasible to add an e2e test to avoid regression?

Adding an e2e test is not a straightforward process because that kind of revert can't be reproduced with an EthereumTransaction. In order to re-create it we have to execute ContractCall SDK call which is out of the relay scope IMO.

I have no problem adding that test if you insist 🚀 🙏.

Great work overall. Blocking as one warning needed to be addressed.
Also, is it feasible to add an e2e test to avoid regression?

Adding an e2e test is not a straightforward process because that kind of revert can't be reproduced with an EthereumTransaction. In order to re-create it we have to execute ContractCall SDK call which is out of the relay scope IMO.

I have no problem adding that test if you insist 🚀 🙏.

Ah I see. Just curious how would you reproduice the problem?

Great work overall. Blocking as one warning needed to be addressed.
Also, is it feasible to add an e2e test to avoid regression?

Adding an e2e test is not a straightforward process because that kind of revert can't be reproduced with an EthereumTransaction. In order to re-create it we have to execute ContractCall SDK call which is out of the relay scope IMO.
I have no problem adding that test if you insist 🚀 🙏.

Ah I see. Just curious how would you reproduice the problem?

Sending a negative amount via ContractCallTransaction will be enough while it accepts int64 (not uint64).

Here is the link to the doc https://docs.hedera.com/hedera/sdks-and-apis/hedera-api/readme-1-1/contractcall#contractcalltransactionbody.

Great work overall. Blocking as one warning needed to be addressed.
Also, is it feasible to add an e2e test to avoid regression?

Adding an e2e test is not a straightforward process because that kind of revert can't be reproduced with an EthereumTransaction. In order to re-create it we have to execute ContractCall SDK call which is out of the relay scope IMO.
I have no problem adding that test if you insist 🚀 🙏.

Ah I see. Just curious how would you reproduice the problem?

Sending a negative amount via ContractCallTransaction will be enough while it accepts int64 (not uint64).

Here is the link to the doc https://docs.hedera.com/hedera/sdks-and-apis/hedera-api/readme-1-1/contractcall#contractcalltransactionbody.

Ah I see. So if it's feasible and do not take crazy amount of time, I would encourage we have an e2e just to make sure no regression later. Thanks much Nikki!

Great work overall. Blocking as one warning needed to be addressed.

Also, is it feasible to add an e2e test to avoid regression?

Adding an e2e test is not a straightforward process because that kind of revert can't be reproduced with an EthereumTransaction. In order to re-create it we have to execute ContractCall SDK call which is out of the relay scope IMO.

I have no problem adding that test if you insist 🚀 🙏.

Ah I see. Just curious how would you reproduice the problem?

Sending a negative amount via ContractCallTransaction will be enough while it accepts int64 (not uint64).

Here is the link to the doc https://docs.hedera.com/hedera/sdks-and-apis/hedera-api/readme-1-1/contractcall#contractcalltransactionbody.

Ah I see. So if it's feasible and do not take crazy amount of time, I would encourage we have an e2e just to make sure no regression later. Thanks much Nikki!

At the least we could mock the CN response that would cause this and have an integration test that ensures the relay responds as expected.

Quality Gate failed

Failed conditions
29.1% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

Codecov Report

Attention: Patch coverage is 84.21053% with 3 lines in your changes missing coverage. Please review.

Project coverage is 85.54%. Comparing base (373f1dc) to head (94e77f6).

@@            Coverage Diff             @@
##             main    #3387      +/-   ##
==========================================
+ Coverage   84.18%   85.54%   +1.36%     
==========================================
  Files          69       69              
  Lines        4711     4726      +15     
  Branches     1048     1051       +3     
==========================================
+ Hits         3966     4043      +77     
+ Misses        428      393      -35     
+ Partials      317      290      -27