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

Implement output for ContractSubmittableResult the same way it is in ContractExecResult #3349

Closed
vminkov opened this issue Mar 23, 2021 · 6 comments
Labels
Support Tracks issues or requests related to troubleshooting, answering questions, and user assistance.

Comments

@vminkov
Copy link
Contributor

vminkov commented Mar 23, 2021

Currently calls with contract.query.method() return the output, but calls with contract.tx.method() do not and in pieces like this one:

    #[ink(storage)]
    pub struct MyContract {
        counter: u32,
    }

    pub enum Error {
        CustomError,
    }

    pub type Result<T> = core::result::Result<T, Error>;

    #[ink(message)]
    pub fn callMethod(&mut self, value: u32) -> Result<()> {
         *self.counter += value;
         if value % 2  {
            Err(Error::CustomError)
         } else {
            Ok(())
        }
    }

it is not possible to extract the output from ContractSubmittableResult - its fields are

[
  "dispatchError",
  "dispatchInfo",
  "events",
  "status",
  "contractEvents"
]

whereas ContractExecResult has:

[
  "debugMessage",
  "gasConsumed",
  "output",
  "result"
]
@jacogr
Copy link
Member

jacogr commented Mar 23, 2021

There is a difference between exec and read - exec sends a transaction, transactions do not return values like a read call does. (The only communication a transaction does have is with events)

@jacogr jacogr added the Support Tracks issues or requests related to troubleshooting, answering questions, and user assistance. label Mar 23, 2021
@vminkov
Copy link
Contributor Author

vminkov commented Mar 24, 2021

Well, this basically means that we have emit events to know the reason why a transaction failed? Is there a better way to do that in ink?

@jacogr
Copy link
Member

jacogr commented Mar 24, 2021

The general and only way a transaction can communicate with the outside world (providing info on success) is via events. For Substrate itself, error conditions are indicated with an Error enum that is returned via the ExtrinsicFailed event itself.

If a failure is meant to emit an event, it would mean the transaction needs to succeed - event are not emitted on ExtrinsicFailed statuses.

I'm no ink! expert (only understand how transactions actually do work), so it may be worth-while asking the team, they would be happy to help.

@RoyTimes
Copy link

RoyTimes commented Apr 6, 2021

I think I came across the same issue at patractlabs/redspot#78 . @vminkov would you mind keeping me posted if you are able to resolve this?

@hychen
Copy link

hychen commented Apr 9, 2021

@RoyTimes The error forwarding of ink! is not implemented and still under discussion.
use-ink/ink#641

@jacogr jacogr closed this as completed May 1, 2021
@polkadot-js-bot
Copy link

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.

@polkadot-js polkadot-js locked as resolved and limited conversation to collaborators May 31, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Support Tracks issues or requests related to troubleshooting, answering questions, and user assistance.
Projects
None yet
Development

No branches or pull requests

5 participants