-
Notifications
You must be signed in to change notification settings - Fork 132
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
Report message dispatch status to source chain #2022
Comments
A couple of questions (sorry - I'm yet to read everything in #2443 carefully):
|
Yes, I think we would only need 1 bit to report success/failure.
In theory |
That's a bummer :/ I thought it is all covered by XCM when I've removed that functionality. But it is kinda strange that this stuff ( That said, I'm not against reverting dispatch-result-removal, if you think we need it. However, please note that this will affect the weight of |
This doesn't seem like it's a huge issue for me -- you can simply implement |
Thanks! Then I wonder why do we need a separate But I guess if it is fine to use |
I hope I'm not missing something. I'm not very familiar with XCM, so take the following with a grain of salt, but: In my opinion the biggest issue with
If we only have a communication between 2 chains let's say A and B and A wants to send some assets to B, probably But if we consider a longer distance scenario things get complicated. In our case Instead if we relay the dispatch result to Also relaying the dispatch status would be more efficient. We would only need to send 1 bit back with the receive_message_delivery_proof which we send anyway, and we would avoid the customizations needed to make But not sure if this is the best solution. Still thinking of alternatives. Couldn't find something trivial yet. Also maybe I'm missing something. But anyway, @svyatonik could you also point me to the commit with the |
Also probably it's highly unlikely, but we could get a decoding error on |
You maybe right - I have no much expertise in XCM as well. I just wanted to avoid reinventing the wheel here. Because I was expecting that everything XCM need from bridges is to deliver blobs (as it was requested last year) (c). Nothing about delivering "dispatch result" or anything like that. So if we need to get dispatch result bits back - let's do it. That's the PR that has removed relaying dispatch result: #1660 |
This is by design actually. XCM is designed to be Asynchronous, and so none of the XCM components assume that you can expect a timely delivery. The reason behind this design decision is exactly as you've discovered -- the complexity of designing a timely message delivery system really high, and likely not generalizable either, so by default XCM assumes asynchronicity. If you want to implement a retry mechanism, then you'll have to implement it on top of XCM. |
Related to #2443
I think we might need to report the message dispatch status from target chain to source chain.
For example for the flow
Rockmine -> BridgeHub Rococo -> BridgeHubWococo -> Wockmint
we might have an XCM message that reachedBridgeHubWococo
, but the dispatch failed. In this case the assets won't be trapped anywhere (more details in this comment) . I think it would be good if we could report the failed dispatch toBridgeHub Rococo
so thatBridgeHub Rococo
could then send aQueryResponse
back toRockmine
to somehow unlock the assets there.@svyatonik do you think this would make sense ?
The text was updated successfully, but these errors were encountered: