build: update `ic-cdk` to `v0.18.7` #489

lpahlavi · 2025-10-03T07:46:43Z

(XC-502) Update the ic-cdk version to v0.18.

(XC-502) In preparation for updating `ic-cdk` to v0.18 in #489, this PR updates the `dfx` version in the top-level `dfx.json`, which is used for deploying canisters for end-to-end tests. Due to the underlying Motoko version upgrade bundled with the newer `dfx`, this change also adds some now-required keywords to the end-to-end test Motoko canister source code.

Cargo.toml

tests/tests.rs

gregorydemay

Generally looks good to me excepted for the ic_cdk error that I would not expose.

gregorydemay · 2025-10-07T15:14:02Z

evm_rpc_client/src/lib.rs

        &self,
        request: Request<Config, Params, CandidOutput, Output>,
-    ) -> Result<Output, (RejectCode, String)>
+    ) -> Result<Output, ic_cdk::call::Error>


this should now be IcError, correct? I would not expose the ic cdk error.

Actually, this is unrelated to canhttp (evm_rpc_client has no dependency on canhttp). The error type here comes from the Runtime interface, and the error type returned by the ic-cdk when making inter-canister calls. What might be confusing is that the ic-cdk error is the same for HTTP outcalls and inter-canister calls.

I agree though that exposing ic_cdk::call::Error is not optimal. Furthermore, similar to canhttp, I would say a Candid decode error is a bug (i.e. the value returned by the EVM RPC canister does not match the Candid type for that endpoint), and we can also combine CallRejected and CallPerformFailed, so in effect we can actually re-use IcError from canhttp...

That being said, I think it's better to define a separate error type for evm_rpc_client. This way, if we make breaking changes to canhttp (which is e.g. likely in the event of a breaking change in the ic-cdk), we reduce the likeliness of having a breaking change for the evm_rpc_client. Additionally, this saves us from adding a dependency on cahttp altogether. WDYT?

Actually, this is unrelated to canhttp (evm_rpc_client has no dependency on canhttp)

Ha right, thanks for pointing that out!

Additionally, this saves us from adding a dependency on cahttp altogether.

yes, I think a separate error type make sense, especially for the public methods.

About IcError. I think here the situation is different from canhttp: we make an inter-canister call to a known canister (the EVM RPC canister) on some endpoint, whereas in canhttp we target one specific endpoint to the management canister. My impression is that here Candid decoding errors might be possible (e.g. non backwards-compatible change on some debug endpoint) and it might be useful to keep the granularity of the error from ic_cdk (Perform/Failed) without exposing them directly so that dev using the client could build something on top (e.g. to know when to retry). WDYT?

Actually that's a very good point! I've added more variants to IcError, LMK what you think!

evm_rpc_client/src/request/mod.rs

src/main.rs

src/rpc_client/eth_rpc/mod.rs

tests/tests.rs

gregorydemay

LGTM, just a comment about the error type!

gregorydemay · 2025-10-20T09:59:11Z

evm_rpc_client/src/lib.rs

        &self,
        request: Request<Config, Params, CandidOutput, Output>,
-    ) -> Result<Output, (RejectCode, String)>
+    ) -> Result<Output, ic_cdk::call::Error>


Actually, this is unrelated to canhttp (evm_rpc_client has no dependency on canhttp)

Ha right, thanks for pointing that out!

Additionally, this saves us from adding a dependency on cahttp altogether.

yes, I think a separate error type make sense, especially for the public methods.

About IcError. I think here the situation is different from canhttp: we make an inter-canister call to a known canister (the EVM RPC canister) on some endpoint, whereas in canhttp we target one specific endpoint to the management canister. My impression is that here Candid decoding errors might be possible (e.g. non backwards-compatible change on some debug endpoint) and it might be useful to keep the granularity of the error from ic_cdk (Perform/Failed) without exposing them directly so that dev using the client could build something on top (e.g. to know when to retry). WDYT?

## 🤖 New release * `evm_rpc_types`: 2.1.0 -> 3.0.0 (✓ API compatible changes) * `evm_rpc_client`: 0.1.0 * `evm_rpc`: 2.5.0 -> 2.6.0 (✓ API compatible changes) <details><summary>Changelog</summary> ## `evm_rpc_types` <blockquote> ## [3.0.0] - 2025-10-20 ### Added - Add conversions between several types in this crate and the corresponding `alloy` types. These conversions are only available with the `alloy` feature ([#465](#465), [#466](#466), [#467](#467), [#476](#476)). - **Breaking:** Add `root` and `cumulativeGasUsed` fields to `TransactionsReceipt` type ([#474](#474)) [3.0.0]: https://github.com/dfinity/evm-rpc-canister/compare/evm_rpc_types-v2.1.0..evm_rpc_types-v3.0.0 </blockquote> ## `evm_rpc_client` <blockquote> ## [0.1.0] - 2025-10-20 ### Added - Add methods to modify RPC config to `RequestBuilder` ([#494](#494)) - Add `alloy` feature flag to `evm_rpc_client` ([#484](#484)) - Add new `json_request` endpoint ([#477](#477)) - Add client support for `eth_getTransactionReceipt` ([#476](#476)) - Add `eth_sendRawTransaction` client support ([#467](#467)) - Add client support for `eth_call` ([#466](#466)) - Add client support for `eth_getTransactionCount` ([#465](#465)) - Add support for `eth_feeHistory` to client ([#460](#460)) - Add support for `eth_getBlockByNumber` to client ([#459](#459)) - Add EVM RPC canister client ([#447](#447)) [0.1.0]: https://github.com/dfinity/evm-rpc-canister/releases/tag/evm_rpc_client-v0.1.0 </blockquote> ## `evm_rpc` <blockquote> ## [2.6.0] - 2025-10-20 ### Added - Add support for `root` and `cumulativeGasUsed` fields in `eth_getTransactionReceipt` response ([#474](#474)) - Add new `json_request` endpoint and deprecate existing `request` endpoint ([#477](#477)) ### Changed - Update `ic-cdk` to `v0.18.7` ([#489](#489)) - Update `dfx` to `v0.29.0` ([#490](#490)) - Cleanup unused dependencies ([#491](#491)) ### Removed - **Breaking**: Remove `getMetrics` endpoint, this is acceptable since it was a debugging endpoint ([#479](#479)) ### Fixed - Add `err_max_response_size_exceeded` to Prometheus metrics ([#487](#487)) [2.6.0]: v2.5.0...v2.6.0 </blockquote> </details> --- This PR was generated with [release-plz](https://github.com/release-plz/release-plz/). --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Louis Pahlavi <[email protected]>

## 🤖 New release * `evm_rpc_types`: 2.1.0 -> 3.0.0 (✓ API compatible changes) * `evm_rpc_client`: 0.1.0 * `evm_rpc`: 2.5.0 -> 2.6.0 (✓ API compatible changes) <details><summary>Changelog</summary> ## `evm_rpc_types` <blockquote> ## [3.0.0] - 2025-10-20 ### Added - Add conversions between several types in this crate and the corresponding `alloy` types. These conversions are only available with the `alloy` feature ([#465](dfinity/evm-rpc-canister#465), [#466](dfinity/evm-rpc-canister#466), [#467](dfinity/evm-rpc-canister#467), [#476](dfinity/evm-rpc-canister#476)). - **Breaking:** Add `root` and `cumulativeGasUsed` fields to `TransactionsReceipt` type ([#474](dfinity/evm-rpc-canister#474)) [3.0.0]: https://github.com/dfinity/evm-rpc-canister/compare/evm_rpc_types-v2.1.0..evm_rpc_types-v3.0.0 </blockquote> ## `evm_rpc_client` <blockquote> ## [0.1.0] - 2025-10-20 ### Added - Add methods to modify RPC config to `RequestBuilder` ([#494](dfinity/evm-rpc-canister#494)) - Add `alloy` feature flag to `evm_rpc_client` ([#484](dfinity/evm-rpc-canister#484)) - Add new `json_request` endpoint ([#477](dfinity/evm-rpc-canister#477)) - Add client support for `eth_getTransactionReceipt` ([#476](dfinity/evm-rpc-canister#476)) - Add `eth_sendRawTransaction` client support ([#467](dfinity/evm-rpc-canister#467)) - Add client support for `eth_call` ([#466](dfinity/evm-rpc-canister#466)) - Add client support for `eth_getTransactionCount` ([#465](dfinity/evm-rpc-canister#465)) - Add support for `eth_feeHistory` to client ([#460](dfinity/evm-rpc-canister#460)) - Add support for `eth_getBlockByNumber` to client ([#459](dfinity/evm-rpc-canister#459)) - Add EVM RPC canister client ([#447](dfinity/evm-rpc-canister#447)) [0.1.0]: https://github.com/dfinity/evm-rpc-canister/releases/tag/evm_rpc_client-v0.1.0 </blockquote> ## `evm_rpc` <blockquote> ## [2.6.0] - 2025-10-20 ### Added - Add support for `root` and `cumulativeGasUsed` fields in `eth_getTransactionReceipt` response ([#474](dfinity/evm-rpc-canister#474)) - Add new `json_request` endpoint and deprecate existing `request` endpoint ([#477](dfinity/evm-rpc-canister#477)) ### Changed - Update `ic-cdk` to `v0.18.7` ([#489](dfinity/evm-rpc-canister#489)) - Update `dfx` to `v0.29.0` ([#490](dfinity/evm-rpc-canister#490)) - Cleanup unused dependencies ([#491](dfinity/evm-rpc-canister#491)) ### Removed - **Breaking**: Remove `getMetrics` endpoint, this is acceptable since it was a debugging endpoint ([#479](dfinity/evm-rpc-canister#479)) ### Fixed - Add `err_max_response_size_exceeded` to Prometheus metrics ([#487](dfinity/evm-rpc-canister#487)) [2.6.0]: dfinity/evm-rpc-canister@v2.5.0...v2.6.0 </blockquote> </details> --- This PR was generated with [release-plz](https://github.com/release-plz/release-plz/). --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Louis Pahlavi <[email protected]>

lpahlavi changed the base branch from main to lpahlavi/XC-412-alloy-feature-flag October 3, 2025 07:47

lpahlavi changed the title ~~build: update ic-cdk~~ build: update ic-cdk to v0.18.7 Oct 3, 2025

lpahlavi force-pushed the lpahlavi/XC-502-update-ic-cdk branch 3 times, most recently from de0c7c5 to 284ebc1 Compare October 3, 2025 15:28

lpahlavi mentioned this pull request Oct 6, 2025

build: update dfx to v0.29.0 #490

Merged

lpahlavi force-pushed the lpahlavi/XC-502-update-ic-cdk branch 2 times, most recently from 6c0f345 to 10c145d Compare October 6, 2025 13:02

lpahlavi requested a review from gregorydemay October 6, 2025 13:15

lpahlavi commented Oct 6, 2025

View reviewed changes

Cargo.toml Outdated Show resolved Hide resolved

lpahlavi force-pushed the lpahlavi/XC-502-update-ic-cdk branch 2 times, most recently from 1865b52 to 9c8da5e Compare October 6, 2025 13:20

Base automatically changed from lpahlavi/XC-412-alloy-feature-flag to main October 6, 2025 13:58

XC-502: Update ic-cdk

7816262

lpahlavi force-pushed the lpahlavi/XC-502-update-ic-cdk branch from 9c8da5e to 7816262 Compare October 6, 2025 13:59

XC-502: Update canhttp to latest commit

2a5f7b7

lpahlavi marked this pull request as ready for review October 7, 2025 09:10

lpahlavi requested a review from a team as a code owner October 7, 2025 09:10

lpahlavi commented Oct 7, 2025

View reviewed changes

tests/tests.rs Show resolved Hide resolved

gregorydemay reviewed Oct 7, 2025

View reviewed changes

lpahlavi added 3 commits October 8, 2025 11:43

Merge branch 'main' into lpahlavi/XC-502-update-ic-cdk

2c912a2

XC-502: Remove #[allow(unused_mut)]

3e62ad3

XC-502: Use custom IcError instead of ic_cdk::call::Error

6693655

lpahlavi requested a review from gregorydemay October 8, 2025 10:46

lpahlavi added 2 commits October 20, 2025 08:51

Merge branch 'main' into lpahlavi/XC-502-update-ic-cdk

97de2ed

XC-502: Update canhttp

81c0510

gregorydemay reviewed Oct 20, 2025

View reviewed changes

XC-502: Increase IcError granularity

b6bfc2f

lpahlavi requested a review from gregorydemay October 20, 2025 12:37

gregorydemay approved these changes Oct 20, 2025

View reviewed changes

lpahlavi merged commit 0aa2b05 into main Oct 20, 2025
12 checks passed

lpahlavi deleted the lpahlavi/XC-502-update-ic-cdk branch October 20, 2025 17:21

github-actions bot mentioned this pull request Oct 20, 2025

chore: release #500

Merged

github-actions bot mentioned this pull request Oct 21, 2025

chore: release #504

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

build: update `ic-cdk` to `v0.18.7` #489

build: update `ic-cdk` to `v0.18.7` #489

Uh oh!

lpahlavi commented Oct 3, 2025 •

edited by atlassian bot

Loading

Uh oh!

Uh oh!

Uh oh!

gregorydemay left a comment

Uh oh!

gregorydemay Oct 7, 2025

Uh oh!

lpahlavi Oct 8, 2025 •

edited

Loading

Uh oh!

gregorydemay Oct 20, 2025

Uh oh!

lpahlavi Oct 20, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gregorydemay left a comment

Uh oh!

gregorydemay Oct 20, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

build: update ic-cdk to v0.18.7 #489

build: update ic-cdk to v0.18.7 #489

Uh oh!

Conversation

lpahlavi commented Oct 3, 2025 • edited by atlassian bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gregorydemay left a comment

Choose a reason for hiding this comment

Uh oh!

gregorydemay Oct 7, 2025

Choose a reason for hiding this comment

Uh oh!

lpahlavi Oct 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gregorydemay Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

lpahlavi Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gregorydemay left a comment

Choose a reason for hiding this comment

Uh oh!

gregorydemay Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

build: update `ic-cdk` to `v0.18.7` #489

build: update `ic-cdk` to `v0.18.7` #489

lpahlavi commented Oct 3, 2025 •

edited by atlassian bot

Loading

lpahlavi Oct 8, 2025 •

edited

Loading