Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Status and execution stages

status

statusExitMeaningWhat to do
ok0The command did what it says. data holds the result.Use data. Look at warnings.
error1 or 2It failed, and the CLI knows the node did not act on it (nothing was sent, the node refused, or it was a read).Branch on error.code. Safe to fix and retry.
uncertain1A request was (or may have been) published and the CLI cannot prove what happened, or the node accepted it and the local write failed.Do not retry blindly. Check the order first. See Recovering.

uncertain only exists for commands that publish a write (order new, the takes, the invoices, the trade steps) and for order sync’s partial local save. Pure reads (order list, order info, message list, schema) are ok or error only: they are safe to repeat.

The three stages

meta describes how far the command got, in three independent dimensions.

publication — did a request leave?

ValueMeaning
not_applicableThis command publishes nothing (order list, message list, order sync, schema).
not_attemptedNothing was published: the command stopped before (bad arguments, no identity, refused PoW…) or every relay explicitly rejected the event.
publishedAt least one relay confirmed accepting the signed request.
unknownNo relay confirmed, but at least one failed ambiguously (timeout, dropped connection after the send): the event may be out there.

daemon_acceptance — what did the Mostro node say?

ValueMeaning
not_applicableNo node request is involved.
unknownNo usable answer (not sent, timed out, malformed).
acceptedThe node answered with the expected action.
rejectedThe node answered cant-do (error.code is node_refused).

persistence — did the local write happen?

ValueMeaning
not_applicableThis command never writes locally (order list, order info, message list, schema).
not_attemptedNo write was called for, or the command stopped before writing.
appliedThe write the outcome calls for was done (an order row, a status update, a reserved trade index).
failedThe write was attempted and failed.

What “the write” is depends on the command:

CommandLocal write
order new, order take-*Reserve/advance the trade index; save the order row with its trade key
order add-invoiceUpdate the order’s local status
order fiat-sent, order release, order cancelUpdate the order’s local status; for a range maker, record the next trade index
bond add-invoiceNothing (not_attempted on success)
order syncInsert rows for orders the store did not know

Allowed combinations

The generated schemas enforce exactly these combinations. The tables read publication / daemon_acceptance / persistence.

Reads: order list, message list, schema

statusStages
oknot_applicable / not_applicable / not_applicable
errornot_applicable / not_applicable / not_applicable

Request without local write: order info

statusStagesTypical codes
okpublished / accepted / not_applicable
errornot_attempted / unknown / not_applicablelocal failures, pow_required, request_rejected
errorunknown / unknown / not_applicablerequest_rejected (ambiguous relay)
errorpublished / unknown / not_applicablereply_timeout, reply_malformed, relay_read_failed, late pow_required
errorpublished / rejected / not_applicablenode_refused

Creating: order new, order take-sell, order take-buy

statusStagesTypical codes
okpublished / accepted / applied
errornot_attempted / unknown / not_attemptedlocal failures, proven request_rejected
errorpublished / rejected / not_attemptednode_refused
uncertainpublished / accepted / failedorder_not_saved (data present)
uncertainpublished / unknown / applied or failedreply_timeout, reply_malformed, relay_read_failed, pow_required
uncertainunknown / unknown / applied or failedrequest_rejected

Here persistence on an uncertain outcome is about the trade index: it is spent whenever the request may have been published, so the next attempt uses a fresh key.

Updating: order add-invoice, order fiat-sent, order release, order cancel

statusStagesTypical codes
okpublished / accepted / applied
okpublished / accepted / not_attemptednothing to record (cancel_requested, invoice_updated)
okpublished / accepted / failedwith warning local_status_stale or trade_index_not_recorded
errornot_attempted / unknown / not_attemptedlocal failures, order_unknown
errorpublished / rejected / not_attemptednode_refused
uncertainpublished / unknown / not_attemptedreply_timeout, reply_malformed, relay_read_failed, pow_required
uncertainunknown / unknown / not_attemptedrequest_rejected

For the trade steps (fiat-sent, release, cancel) an uncertain outcome may also show applied or failed: the maker of a range order reserved a trade index for the child order, and persistence tells whether it was recorded.

bond add-invoice

statusStages
okpublished / accepted / not_attempted
errornot_attempted / unknown / not_attempted or published / rejected / not_attempted
uncertainpublished / unknown / not_attempted or unknown / unknown / not_attempted

order sync

statusStagesMeaning
oknot_applicable / not_applicable / appliedAt least one row saved
oknot_applicable / not_applicable / not_attemptedNothing to save
errornot_applicable / not_applicable / not_applicable or not_attemptedFailed before or after reading, before saving
uncertainnot_applicable / not_applicable / failedSome rows saved, then one failed (order_not_saved)

Unresolved or rejected before running

SituationStages
command: null (unknown command, removed spelling)not_attempted / unknown / not_attempted
Legacy command with --output json (output_not_supported)not_attempted / unknown / not_attempted

Reading stages in a wrapper

Most of the time status + error.code is enough. Stages answer two finer questions:

  • “Could the node have acted?” — publication is published or unknown.
  • “Is my local store in step?” — persistence is failed ⇒ the node moved on but the local row did not; follow the warning or error advice (often: order info, order sync).