Enum OrderStatus 

pub enum OrderStatus {
    Active,
    Filled,
    Cancelled,
    Expired,
    Killed,
    Rejected,
    LiquidationCancelled,
    Pending,
    Delayed,
}

Current lifecycle state of an order within the matching engine.

This enum tracks the complete lifecycle of orders from submission through final disposition. Each status represents a distinct state with specific implications for order behavior, visibility, and further actions.

Status Flow

A submitted order lands in one of three live states and moves on from there:

live states
  Active   — plain order: resting on the book, or matching
  Delayed  — aggressive order held back by the maker shield
  Pending  — order carrying a conditional that has not triggered yet

Delayed → Active                        (shield window elapses)
Pending → Active                        (conditional triggers)
Pending → Expired | Cancelled           (conditional expires, or is cancelled)
Active  → Filled | Cancelled | Expired | LiquidationCancelled

terminal at submission, never live:
  Rejected — validation refused the order; `error` carries the OrderError
  Killed   — a FOK order could not be filled in full

Status Categories

Live States

• Active: Order is live and can be matched
• Delayed: Aggressive order queued behind the maker shield
• Pending: Order held by the conditional engine, not yet triggered

Final States (Terminal)

• Filled: Order completely executed
• Cancelled: Order cancelled by the client
• Expired: GTT expiry, or a conditional that expired without triggering
• Killed: A FOK order could not be filled in full
• Rejected: Order rejected by validation, carries an OrderError
• LiquidationCancelled: Order cancelled while the account was liquidated

Usage

Order status is used for:

• Client-side order tracking and display
• Determining valid order operations (cancel, modify, etc.)
• Audit trails and reporting
• Risk management and position tracking

Examples

Status checking and display

use types::common::OrderStatus;

let status = OrderStatus::Active;
println!("Order status: {}", status); // Prints: "Order status: Active"

// Check if order can be canceled
let can_cancel = matches!(status, OrderStatus::Active);
assert_eq!(can_cancel, true);

Pattern matching for order management

use types::common::OrderStatus;

fn handle_order_status(status: OrderStatus, order_id: u64) {
    match status {
        OrderStatus::Active => {
            println!("Order {} is active and can be canceled", order_id);
        }
        OrderStatus::Filled => {
            println!("Order {} completed successfully", order_id);
        }
        OrderStatus::Cancelled => {
            println!("Order {} was canceled", order_id);
        }
        OrderStatus::Rejected => {
            println!("Order {} was rejected during validation", order_id);
        }
        _ => println!("Order {} in final state: {}", order_id, status),
    }
}

JSON Representation

Serialized as the variant name. All nine:

"Active"
"Filled"
"Cancelled"
"Expired"
"Killed"
"Rejected"
"LiquidationCancelled"
"Pending"
"Delayed"

Variants

Active

Order is active and available for matching in the order book.

This is the primary working state for orders. Active orders:

• Can be matched against incoming orders
• Are visible in market data and order book
• Can be canceled or modified (if supported)
• Consume account margin/balance

Transitions To

• Filled: When completely executed
• Cancelled: When manually canceled
• Expired: When TTL/expiry reached
• Killed: When forcibly terminated

Operations Allowed

• Cancel order
• Modify order (system dependent)
• Query order status

Filled

Order has been completely executed.

This is a terminal state indicating successful order completion. Filled orders:

• Have no remaining quantity to execute
• Generated execution reports and trade confirmations
• Updated account positions and balances
• Are preserved for audit and reporting purposes

Characteristics

• Terminal state (no further transitions)
• Successful completion
• All quantity executed
• Positions and balances updated

Operations Allowed

• Query order details and execution history
• Generate trade reports

Cancelled

Order was manually canceled before completion.

This terminal state indicates the order was deliberately canceled, either by the client or system administrator. Canceled orders:

• Stop participating in matching
• Release reserved margin/balance
• May have partial fills before cancellation
• Preserve execution history up to cancellation point

Causes

• Client-initiated cancellation
• Risk management system cancellation
• Administrator intervention
• System maintenance procedures

Characteristics

• Terminal state
• Deliberately stopped
• May have partial execution history
• Resources released back to account

Expired

Order automatically expired due to time-based rules.

This terminal state occurs when orders reach their configured expiry conditions. Expired orders:

• Were subject to GTT (Good Till Time) time limits
• Automatically removed at specified timestamp
• May have partial fills before expiry
• Release reserved resources

Triggers

• GTT expiry timestamp reached
• Session/market close (if configured)
• System-defined maximum order lifetime

Characteristics

• Terminal state
• Time-based automatic removal
• System-initiated (not client-initiated)
• May have execution history before expiry

Killed

A Fill-or-Kill order that could not be filled in full.

This is the only thing that produces Killed. The engine sets it when a FOK order’s reachable volume is short of its quantity — because the book is thin, because the trading band puts the rest of the book out of reach, or because the open-interest cap clips the fill. stopped_quantity carries the whole order and error is OrderError::FokOrderCannotBeFullyFilled.

Characteristics

• Terminal, and reached at submission — the order never rests
• Nothing is filled: filled_quantity is zero
• A routine outcome, not an incident: this is how FOK declines

Rejected

Order was rejected during validation and never became active.

This terminal state indicates the order failed validation checks and was never placed in the order book. Rejected orders:

• Failed business logic or technical validation
• Never consumed margin or participated in matching
• Include specific error details about rejection reason
• Allow immediate resubmission with corrections

Common Causes

• Insufficient balance or margin
• Invalid price or quantity parameters
• Market or account restrictions
• Technical validation failures

Characteristics

• Terminal state
• Failed validation before activation
• No impact on account balances/positions
• Includes error details for client action

Associated Data

Typically accompanied by OrderError details explaining the specific rejection reason.

LiquidationCancelled

Order was cancelled as part of a liquidation process.

This terminal state indicates the order was cancelled because the account holding this order was being liquidated. During liquidation, all open orders are typically cancelled to free up margin before closing positions.

Characteristics

• Terminal state
• Part of account liquidation process
• Order cancelled to free margin
• Distinguished from user-initiated cancellation

Context

This status helps differentiate between normal user cancellations and system-initiated cancellations during liquidation events, which is important for audit trails and understanding account history.

Pending

Order carries a conditional that has not triggered yet.

The order is parked in the conditional engine — not on the book, not matchable — while its trigger condition is monitored. Nothing bounds how long that lasts: a stop that never triggers stays Pending until it is cancelled or its conditional expiry fires. This is the ordinary resting state of a stop or take-profit, not a sign of congestion.

Transitions To

• Active: the conditional triggered; the order goes to the book
• Expired: the conditional’s expiry elapsed with trigger false
• Cancelled: cancelled by the client — dormant orders are cancellable
• Rejected: trigger-time validation refused it (see OrderError)

Characteristics

• Not terminal
• Not in the order book, cannot be matched
• The order’s conditional.status carries the finer state ([ConditionalStatus::Active], [ConditionalStatus::PendingActivation])

Delayed

Aggressive order has been placed in a queue

Trait Implementations

impl Clone for OrderStatus

fn clone(&self) -> OrderStatus

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Copy for OrderStatus

impl Debug for OrderStatus

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

Formats the value using the given formatter.

impl Default for OrderStatus

fn default() -> OrderStatus

Returns the “default value” for a type.

impl<'de> Deserialize<'de> for OrderStatus

fn deserialize<__D>( __deserializer: __D, ) -> Result<OrderStatus, <__D as Deserializer<'de>>::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Display for OrderStatus

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

Formats the value using the given formatter.

impl Eq for OrderStatus

impl PartialEq for OrderStatus

fn eq(&self, other: &OrderStatus) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl Serialize for OrderStatus

fn serialize<__S>( &self, __serializer: __S, ) -> Result<<__S as Serializer>::Ok, <__S as Serializer>::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl StructuralPartialEq for OrderStatus