Type Alias: WaitForReceiptError

type WaitForReceiptError = {
  description: string;
  receipt?: undefined;
  revertData?: Bytes;
  status: Exclude<WaitForReceiptStatus, typeof Success>;
};

Defined in: apps/submitter/lib/handlers/waitForReceipt/types.ts:59

Failed waitForReceipt call.

Properties

description

description: string;

Defined in: apps/submitter/lib/handlers/waitForReceipt/types.ts:82

Description of the problem.

receipt?

optional receipt: undefined;

Defined in: apps/submitter/lib/handlers/waitForReceipt/types.ts:84

revertData?

optional revertData: Bytes;

Defined in: apps/submitter/lib/handlers/waitForReceipt/types.ts:79

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 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, this will always be undefined or empty. !!

We can't parse the revert data from onchain execution — 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.

status

status: Exclude<WaitForReceiptStatus, typeof Success>;

Defined in: apps/submitter/lib/handlers/waitForReceipt/types.ts:60