Decode reject reason at sponsoredTransactionAuction backend #88
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
DOBEN
changed the title
DOBEN
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose
Related to #87
Blocked/Problem: This backend can not decode the reject reason and shows a limitation of our current approach.
The limitation occurs when there is a chain of smart contract calls (where the errors have not been nested in the ErrorSchema) and the rejection happens in a smart contract that was initially called by another smart contract. For example, this dapp uses 2 unrelated smart contracts (the
cis2-tokencontract and theauctioncontract with no combined ErrorSchema). Theauctioncontract could be replaced with any other defi protocol and as such we cannot nest the ErrorSchema into thecis2-token(and embed the nested ErrorSchema into thecis2-tokencontract) to be generic enough to interact with any defi protocol. The transaction execution first invokes thecis2-tokencontract which then invokes theautioncontract which might reject (in this case we run into some limitation to decode the reject reason).Some research needs to be done here on the best approach/solution since I expect that the contract call traces are not available in the
contract-clientof the Rust SDK currently which are needed to decode the reject reason without relying on a nested ErrorSchema.Changes
_Describe the changes that were needed.