Type Alias: ExecuteError

type ExecuteError = {
  description: string;
  receipt?: undefined;
  revertData?: Bytes;
  stage: "simulate" | "submit" | "execute";
  status: Exclude<ExecuteStatus, typeof Success>;
};

Defined in: apps/submitter/lib/handlers/execute/types.ts:64

Failed execute call.

Properties

description

description: string;

Defined in: apps/submitter/lib/handlers/execute/types.ts:89

Description of the problem.

receipt?

optional receipt: undefined;

Defined in: apps/submitter/lib/handlers/execute/types.ts:91

revertData?

optional revertData: Bytes;

Defined in: apps/submitter/lib/handlers/execute/types.ts:86

If the status string ends in "Reverted" or "Rejected", this will hold the associated revert or rejection data, if available.

Note that this will be different from the revert data of the simulation or onchain execution of the EVM tx that carried the boop, as first of all it might not have reverted (e.g. Onchain.ExecuteReverted does not cause the transaction to revert when executed onchain), and second we use "carrier errors" to transmit to tag the real errors with their context.

At the moment, we can't parse the revert data from onchain execution, so when provided, this will always be an error detected during simulation — this is an EVM RPC limitation that is difficult to work around (it requires tracing the transaction in its intra-block context).

Onchain reverts should be rare, as the system is set up to avoid them — they can only result from incorrectly implemented accounts and paymasters, or from bugs in the submitter.

stage

stage: "simulate" | "submit" | "execute";

Defined in: apps/submitter/lib/handlers/execute/types.ts:68

Whether the error occurred at the simulation or execution stages.

status

status: Exclude<ExecuteStatus, typeof Success>;

Defined in: apps/submitter/lib/handlers/execute/types.ts:65