-
Notifications
You must be signed in to change notification settings - Fork 130
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
Remove dispatch_result field #1660
Conversation
/// the target chain to the message submitter at the source chain. If you're using immediate | ||
/// call dispatcher, then it'll be result of the dispatch - `true` if dispatch has succeeded | ||
/// and `false` otherwise. | ||
pub dispatch_result: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@svyatonik
so this is now kind of "fire and forget"?
so, we dont want to add some information if dispatch was ok/failed to the Event::MessagesDelivered
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. In our previous API, the messaging pallet was the entrypoint for all messages, so we were building applications around that palet (e.g. atomic token swap - https://github.com/paritytech/parity-bridges-common/tree/c7c6f0ce5e88b3ba9cdcd817f4286e76221b8222/modules/token-swap). There we were actually using this (one-bit) dispatch_result
to see if our call has succeeded or not.
Now the XCM infra is the central point, so applications are built around XCM. We are just transport, so no extra logic is required. E.g. XCM has its own mechanism to send responses back to the caller (see ReportHolding
, ReportTransactStatus
, ReportError
XCM instructions). Hence we don't need our own mechanism anymore
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, got it, thank you :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
* Use an actual Result inside MessageDispatchResult We need this in order to distinguish between Ok and Err * Revert #1660 * Fixes + simplifications * Implement review suggestions
* remove dispatch_result field * fix benchmarks
* Use an actual Result inside MessageDispatchResult We need this in order to distinguish between Ok and Err * Revert paritytech#1660 * Fixes + simplifications * Implement review suggestions
* remove dispatch_result field * fix benchmarks
* Use an actual Result inside MessageDispatchResult We need this in order to distinguish between Ok and Err * Revert paritytech#1660 * Fixes + simplifications * Implement review suggestions
#1638