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

dryRunApi.dryRunCall: redundant items in forwardedXcms #5878

Closed
mrshiposha opened this issue Sep 30, 2024 · 3 comments · May be fixed by #6002
Closed

dryRunApi.dryRunCall: redundant items in forwardedXcms #5878

mrshiposha opened this issue Sep 30, 2024 · 3 comments · May be fixed by #6002
Assignees
Labels
T4-runtime_API This PR/Issue is related to runtime APIs. T6-XCM This PR/Issue is related to XCM.

Comments

@mrshiposha
Copy link
Contributor

When dry-running the polkadotXcm.transferAssets extrinsic using the new dryRunApi, AssetHub reports excessive items in the forwardedXcms field.

For instance, if one constructs an extrinsic to transfer USDT to a different chain and dry-runs it to obtain the forwarded messages, they will get the following:

  1. an empty list of messages heading to the relay chain
  2. the ReserveAssetDeposited message heading to the destination chain repeated several times

You can see this by dry-running the following using any account with at least 1 USDT as the Origin.

0x1f0b04010100411f0400010100bee592c66e1f3bd7f438a0800cbd2f2519ccc0ce763325091f778f1809cdbd4704040002043205011f0002093d000000000000

The cause

  1. The InspectMessageQueue trait implementation for tuples doesn't discard empty lists, which is the cause of the first issue.
  2. The InspectMessageQueue trait implementation for SovereignPaidRemoteExporter reuses the Router passed as the generic parameter. AssetHub's XCM config contains bridge routers that use SovereignPaidRemoteExporter and pass the XcmpQueue to the generic parameter. Thus, XcmpQueue's messages got into the final list several times.
@bkchr
Copy link
Member

bkchr commented Oct 1, 2024

CC @franciscoaguirre

@franciscoaguirre
Copy link
Contributor

Nice catch! I'm working on fixing this alongside #5708

@franciscoaguirre franciscoaguirre self-assigned this Oct 1, 2024
@franciscoaguirre franciscoaguirre added T4-runtime_API This PR/Issue is related to runtime APIs. T6-XCM This PR/Issue is related to XCM. labels Oct 2, 2024
github-merge-queue bot pushed a commit that referenced this issue Oct 10, 2024
# Description

This PR addresses
#5878.

After dry running an xcm on asset hub, we had redundant xcms showing up
in the `forwarded_xcms` field of the dry run effects returned.
These were caused by two things:
- The `UpwardMessageSender` router always added an element even if there
were no messages.
- The two routers on asset hub westend related to bridging (to rococo
and sepolia) getting the message from their queues when their queues is
actually the same xcmp queue that was already contemplated.

In order to fix this, we check for no messages in UMP and clear the
implementation of `InspectMessageQueues` for these bridging routers.
Keep in mind that the bridged message is still sent, as normal via the
xcmp-queue to Bridge Hub.
To keep on dry-running the journey of the message, the next hop to
dry-run is Bridge Hub.
That'll be tackled in a different PR.

Added a test in `bridge-hub-westend-integration-tests` and
`bridge-hub-rococo-integration-tests` that show that dry-running a
transfer across the bridge from asset hub results in one and only one
message sent to bridge hub.

## TODO
- [x] Functionality
- [x] Test

---------

Co-authored-by: command-bot <>
@franciscoaguirre
Copy link
Contributor

Closing since #5913 was merged to master and backported to stable2407 and stable2409

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T4-runtime_API This PR/Issue is related to runtime APIs. T6-XCM This PR/Issue is related to XCM.
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants