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

Fix DryRunApi client-facing XCM versions #7438

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

mrshiposha
Copy link
Contributor

@mrshiposha mrshiposha commented Feb 3, 2025

Description

Fixes #7413

Integration

This PR makes breaking changes to the DryRunApi. The signature of the dry_run_call is changed, and the XCM version of the return values of dry_run_xcm now follows the version of the input XCM program.

If needed, this PR can be reworked so that the Runtime API is assigned a new version by adding a changed_in attribute to the dry_run_call.

Review Notes

  • The DryRunApi is modified
  • Added the Router::clear_messages to dry_run_xcm common implementation
  • The common implementation in the pallet-xcm is modified accordingly
  • The DryRunApi tests are modified to account for testing old XCM versions
  • The implementation from the pallet-xcm is used where it was not used (including the DryRunApi tests)
  • All the runtime implementations are modified according to the Runtime API change

@mrshiposha mrshiposha requested a review from a team as a code owner February 3, 2025 15:30
@@ -2513,6 +2513,7 @@ impl<T: Config> Pallet<T> {
/// Meant to be used in the `xcm_runtime_apis::dry_run::DryRunApi` runtime API.
pub fn dry_run_call<Runtime, Router, OriginCaller, RuntimeCall>(
origin: OriginCaller,
xcms_version: XcmVersion,
call: RuntimeCall,
Copy link
Contributor

Choose a reason for hiding this comment

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

I am just wondering why do we pass RuntimeCall parameter to dry_run_call and VersionedXcm<RuntimeCall> parameter to dry_run_xcm function?

Using let xcm_version = xcm.identify_version(); looks cleaner...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What do you mean? :)

The RuntimeCall is necessary for dry_run_call since it expects an encoded call to dispatch it and record its effects.

The VersionedXcm<RuntimeCall> for dry_run_xcm is also necessary since it needs to dry-run the supplied program.

Comment on lines 292 to 309
fn dry_run_reserve_asset_transfer_latest() {
dry_run_reserve_asset_transfer_common(XCM_VERSION);
}

#[test]
fn dry_run_reserve_asset_transfer_v5() {
dry_run_reserve_asset_transfer_common(5);
}

#[test]
fn dry_run_reserve_asset_transfer_v4() {
dry_run_reserve_asset_transfer_common(4);
}

#[test]
fn dry_run_reserve_asset_transfer_v3() {
dry_run_reserve_asset_transfer_common(3);
}
Copy link
Contributor

@x3c41a x3c41a Feb 4, 2025

Choose a reason for hiding this comment

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

You can utilise table-driven tests for this matter

#[test]
fn dry_run_reserve_asset_transfer_versions() {
    let test_cases = [XCM_VERSION, 5, 4, 3];

    for &version in &test_cases {
        dry_run_reserve_asset_transfer_common(version);
    }
}

same below

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

Note: this uncovered another bug (although I'm not sure it can be easily reproduced in production): the Router's messages weren't cleared before XCM dry-running in the dry_run_xcm.

See this commit: 1d77746

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.

DryRunApi.dryRunCall always produces the latest XCM version report
2 participants