ErrorObjectExt

sui_jsonrpc::error

Trait ErrorObjectExt 

Source 
pub trait ErrorObjectExt<'a> {
    const TRANSIENT_ERROR_CODE: i32;
    const TRANSACTION_EXECUTION_CLIENT_ERROR_CODE: i32;

    // Required methods
    fn is_transient_error(&self) -> bool;
    fn is_execution_error(&self) -> bool;
    fn is_object_unavailable_for_consumption(&self) -> bool;
    fn is_object_not_found(&self) -> bool;
    fn is_transaction_retried_success(&self) -> bool;
    fn as_object_not_found(&self) -> Option<(Address, Option<u64>)>;
}
Available on crate feature client-api only.
Expand description

Helpers to inspect the error type from JSON-RPC calls.

JSON-RPC error object codes taken from the original implementation.

See the source for codes and messages in the quorum driver FN API.

This is an extension trait for the following impl:

ⓘ
#[extension(pub trait ErrorObjectExt)]
impl< 'a > for ErrorObject < 'a >

Required Associated Constants§

Source

const TRANSIENT_ERROR_CODE: i32

Source

const TRANSACTION_EXECUTION_CLIENT_ERROR_CODE: i32

Required Methods§

Source

fn is_transient_error(&self) -> bool

Transient error, suggesting it may be possible to retry.

§Example error messages
  • Transaction timed out before reaching finality
  • Transaction failed to reach finality with transient error after X attempts
  • Transaction is not processed because […] of validators by stake are overloaded with certificates pending execution.
Source

fn is_execution_error(&self) -> bool

Error in transaction execution (pre-consensus)

§Example error messages
  • Invalid user signature
  • Failed to sign transaction by a quorum of validators because one or more of its objects is {reason}. {retried_info} Other transactions locking these objects: […]
    • reason:
      • equivocated until the next epoch
      • reserved for another transaction
    • retried_info: Retried transaction […] (success/failure) because it was able to gather the necessary votes
  • Transaction validator signing failed due to issues with transaction inputs, please review the errors and try again: {reason}
    • reason:
      • Balance of gas object […] is lower than the needed amount
      • Object […] not available for consumption, current version: […]
      • Could not find the referenced object […] at version […]
Source

fn is_object_unavailable_for_consumption(&self) -> bool

Error with message “Object […] not available for consumption, current version: […]”.

TLDR: usually happens when the client’s state sync is lagging too much.

Note that this may not be the single reason why the transaction failed. Other errors related to the transaction inputs may be present.

May be due to state sync lag. For example, the client submits two transactions in quick succession but doesn’t sync owned objects quick enough for the second transaction, therefore it uses the same owned object reference twice.

Source

fn is_object_not_found(&self) -> bool

Like Self::as_object_not_found, but doesn’t extract the object id and version.

Source

fn is_transaction_retried_success(&self) -> bool

Whether the transaction didn’t fail because the RPC retried the submission and it succeeded.

The message for such an error looks like:

Failed to sign transaction by a quorum of validators because one or more of its objects is reserved for another transaction. Retried transaction [...] (succeeded) because it was able to gather the necessary votes
Source

fn as_object_not_found(&self) -> Option<(Address, Option<u64>)>

Error with InvalidParams code and message “Error checking transaction input objects: ObjectNotFound { … }”

TLDR: usually happens when the client’s state sync is faster than the full node’s.

Seen in practice when dry-running a transaction and the full node hasn’t synchronized yet with the effects of a previous one.

Dyn Compatibility§

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.

Implementations on Foreign Types§

Source§

impl<'a> ErrorObjectExt<'a> for ErrorObject<'a>

Helpers to inspect the error type from JSON-RPC calls.

JSON-RPC error object codes taken from the original implementation.

See the source for codes and messages in the quorum driver FN API.

Source§

fn is_transient_error(&self) -> bool

Transient error, suggesting it may be possible to retry.

§Example error messages
  • Transaction timed out before reaching finality
  • Transaction failed to reach finality with transient error after X attempts
  • Transaction is not processed because […] of validators by stake are overloaded with certificates pending execution.
Source§

fn is_execution_error(&self) -> bool

Error in transaction execution (pre-consensus)

§Example error messages
  • Invalid user signature
  • Failed to sign transaction by a quorum of validators because one or more of its objects is {reason}. {retried_info} Other transactions locking these objects: […]
    • reason:
      • equivocated until the next epoch
      • reserved for another transaction
    • retried_info: Retried transaction […] (success/failure) because it was able to gather the necessary votes
  • Transaction validator signing failed due to issues with transaction inputs, please review the errors and try again: {reason}
    • reason:
      • Balance of gas object […] is lower than the needed amount
      • Object […] not available for consumption, current version: […]
      • Could not find the referenced object […] at version […]
Source§

fn is_object_unavailable_for_consumption(&self) -> bool

Error with message “Object […] not available for consumption, current version: […]”.

TLDR: usually happens when the client’s state sync is lagging too much.

Note that this may not be the single reason why the transaction failed. Other errors related to the transaction inputs may be present.

May be due to state sync lag. For example, the client submits two transactions in quick succession but doesn’t sync owned objects quick enough for the second transaction, therefore it uses the same owned object reference twice.

Source§

fn is_object_not_found(&self) -> bool

Like Self::as_object_not_found, but doesn’t extract the object id and version.

Source§

fn is_transaction_retried_success(&self) -> bool

Whether the transaction didn’t fail because the RPC retried the submission and it succeeded.

The message for such an error looks like:

Failed to sign transaction by a quorum of validators because one or more of its objects is reserved for another transaction. Retried transaction [...] (succeeded) because it was able to gather the necessary votes
Source§

fn as_object_not_found(&self) -> Option<(Address, Option<u64>)>

Error with InvalidParams code and message “Error checking transaction input objects: ObjectNotFound { … }”

TLDR: usually happens when the client’s state sync is faster than the full node’s.

Seen in practice when dry-running a transaction and the full node hasn’t synchronized yet with the effects of a previous one.

Source§

const TRANSIENT_ERROR_CODE: i32 = -32_050i32

Source§

const TRANSACTION_EXECUTION_CLIENT_ERROR_CODE: i32 = -32_002i32

Implementors§