Enum ExecutionError 

#[non_exhaustive]
pub enum ExecutionError {
    TokenExpired,
    TokenInvalid(String),
    CodeMismatch {
        expected_hash: String,
        actual_hash: String,
    },
    ContextChanged,
    UserMismatch,
    BackendError(String),
    Timeout(u32),
    ValidationRequired,
    RuntimeError {
        message: String,
    },
    RequestRefused {
        message: String,
    },
    InvalidScript {
        message: String,
    },
}

Errors that can occur during execution.

#[non_exhaustive] since 0.7: a new failure class is a new variant, and a downstream match must carry a wildcard arm rather than break on each one. Adding ExecutionError::RequestRefused is what made the enum non-exhaustive in the first place; it could not be added to an exhaustive enum without breaking every downstream match, so the two changes travel together.

Variants (Non-exhaustive)

Non-exhaustive enums could have additional variants added in future. Therefore, when matching against variants of non-exhaustive enums, an extra wildcard arm must be added to account for any future variants.

TokenExpired

TokenInvalid(String)

CodeMismatch

Fields

expected_hash: String

actual_hash: String

ContextChanged

UserMismatch

BackendError(String)

Timeout(u32)

ValidationRequired

RuntimeError

Fields

message: String

RequestRefused

A request the script made was REFUSED before it was sent: by the SDK’s path-placeholder floor, by a non-scalar path or query value, or by an embedder’s outbound-request policy.

Distinct from ExecutionError::RuntimeError because the two have different owners. A runtime fault is the server’s; a refused request is the CALLER’s to fix by changing what the script sends, so a tool handler should report it as a tool-level rejection the model can act on and never as an internal error. Until 0.7 both were RuntimeError, and a policy refusal reached the model as Internal error: Execution error: Runtime error: ....

message is value-free where it is raised (it names the rule and the declared expectation, never a rejected byte), and the plan executor keeps it value-free when it adds the method and result variable.

Fields

message: String

InvalidScript

The script itself cannot be compiled: a syntax error, a construct the JavaScript subset does not support, or a call shape the plan compiler rejects (api.get('/x/' + id) instead of a template literal).

The CALLER wrote the script, so it is the caller’s to fix, and a tool handler should report it as a tool-level rejection the model can act on, never as an internal error. Until 0.7.2 this was a ExecutionError::RuntimeError reading Compilation failed: ..., which hid a caller mistake behind a label for a server fault.

message comes from CompileError::caller_message: the compiler’s own guidance for a construct, never a fragment of the submitted code.

Fields

message: String

Trait Implementations

impl Debug for ExecutionError

fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter.

impl Display for ExecutionError

fn fmt(&self, __formatter: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter.

impl Error for ExecutionError

fn source(&self) -> Option<&(dyn Error + 'static)>

Returns the lower-level source of this error, if any.

fn description(&self) -> &str

👎Deprecated since 1.42.0:

use the Display impl or to_string()

fn cause(&self) -> Option<&dyn Error>

👎Deprecated since 1.33.0:

replaced by Error::source, which can support downcasting

fn provide<'a>(&'a self, request: &mut Request<'a>)

🔬This is a nightly-only experimental API. (error_generic_member_access)

Provides type-based access to context intended for error reports.