Differentiate successful and failed callback

[MaksymZavershynskyi]

We need for a function to differentiate result of a successful and failed callback. Currently, when we declare function that expects a callback like this:

pub fn callback_receiver(&self, #[callback] arg0: A, arg1: B, #[callback] arg2: C) {
}

It will fail if execution of whatever produced arg0 or arg2 failed. Instead it should be:

pub fn callback_receiver(&self, #[callback_result] arg0: Result<A>, arg1: B, #[callback_result] arg2: Result<C>) {
// Code that handles cases of arg0 and arg2 errors.
}

[evgenykuzyakov]

#138

[mikedotexe]

Want to note that this has become important to two partners looking to build on NEAR.

[evgenykuzyakov]

TODO:

• Implement PromiseResult as a type, which is Result<T, PromiseError>
• Implement PromiseError, for now there is 3 types Failed, Missing and NotReady, but NotReady is unreachable. Missing is when the number of input dependencies is less than the expected number of callback result arguments
• Implement callback_result macro that expects PromiseResult<T>
• Soft rename callback to callback_unwrap and mark callback as deprecated.

[austinabell]

TODO:

• Implement PromiseResult as a type, which is Result<T, PromiseError>
• Implement PromiseError, for now there is 3 types Failed, Missing and NotReady, but NotReady is unreachable. Missing is when the number of input dependencies is less than the expected number of callback result arguments
• Implement callback_result macro that expects PromiseResult<T>
• Soft rename callback to callback_unwrap and mark callback as deprecated.

And any thoughts on what to do with callback_vec wrt this? Can just open a separate issue for this, but curious if anyone has thoughts

[matklad]

Missing is when the number of input dependencies is less than the expected number of callback result arguments

I wonder if this needs to be an error type, or a panic. Naively, it seems that the number of input promises is a static property of the contract, and, if you are missing a promise, this is a bug. Bugs in Rust are generally handled via a panic.

Are there cases where we might want to recover from a missing promise?

[austinabell]

TODO:

• Implement PromiseResult as a type, which is Result<T, PromiseError>
• Implement PromiseError, for now there is 3 types Failed, Missing and NotReady, but NotReady is unreachable. Missing is when the number of input dependencies is less than the expected number of callback result arguments
• Implement callback_result macro that expects PromiseResult<T>
• Soft rename callback to callback_unwrap and mark callback as deprecated.

Opting against having a PromiseResult type since one already existed and is used in env. It's just a convenience wrapper, so the type will be Result<T, PromiseError>, but can create a convenience type called CallbackResult or something but prob best to be careful adding more of these.

Also, currently confused on how Missing could ever be hit, but maybe it'll be more clear when implementing. (nevermind, it was just for vector results)