Cancelling & Managing Orders¶
Objective¶
Master the STATUS, ORDERS, and CANCEL commands for understanding gateway
state, inspecting resting orders, and managing the order lifecycle.
Pre-reading in the User Guide
Prerequisites¶
- Chapters 01–07 completed.
- At least one connected trader gateway with resting orders to manage.
Exercise 1: Cancel a Resting Order¶
Place an order and then cancel it:
Note the order_id, then:
Expected: cancellation confirmed.
RTAG identifies this cancel request. The engine echoes it on the CANCELLED
response or rejected ACK, which makes retries and concurrent cancel tests easier
to audit.
The original order TAG is echoed separately, so a client can tell which order
was acted on and which cancel request completed.
Checkpoint: order cancelled; ORDERS no longer lists it as resting.
Exercise 2: Cancel a Partially Filled Order¶
-
Place a large limit buy at an aggressive price (to get a partial fill from the MM):
-
After partial fill, cancel the remainder:
Expected: the unfilled portion is cancelled; the filled portion remains executed.
Checkpoint: cancel succeeds; filled qty preserved.
Exercise 3: Compare STATUS and ORDERS¶
Place a fresh resting order so the gateway has something to inspect:
First run STATUS:
STATUS gives a quick gateway/session summary: gateway ID, known symbols,
cached order counts by lifecycle state, cached quote legs, and position symbols.
It is useful for a fast health check, but it is not the detailed order table.
Now inspect the actual orders:
ORDERS is the gateway command for detailed order inspection. It displays order
ID, symbol, side, type, TIF, price, quantity, remaining quantity, and status for
orders belonging to your gateway.
Use STATUS when you need a quick health pulse. Use ORDERS when you are
debugging one specific order lifecycle.
Checkpoint: STATUS shows summary counts; ORDERS shows the full order row and ID.
Exercise 4: Inspect Resting Order Details¶
Find your order in the table. The response includes:
symbol,side,type,price,qty- remaining quantity
status(NEW, PARTIAL, FILLED, CANCELLED)tif, last update time
Checkpoint: ORDERS returns full details for each resting order.
Exercise 5: Cancel a Non-Existent Order¶
Expected: rejection — order not found, with REJECT_CODE=ORDER_NOT_FOUND.
Checkpoint: error message returned cleanly.
Exercise 6: Cancel Another Gateway's Order¶
Try cancelling an order belonging to TRADER02:
Expected: rejection — you can only cancel your own orders, with
REJECT_CODE=NOT_OWNER.
Checkpoint: cross-gateway cancel rejected.
Exercise 7: Admin Kill Switch¶
From the admin gateway, cancel all orders for a specific gateway:
All of TRADER01's resting orders are cancelled.
Or cancel all orders for a specific symbol across all gateways:
Checkpoint: admin commands successfully cancel orders.
Exercise 8: Inspect SYMBOLS Metadata from Gateway¶
Request the symbol catalog:
Look for metadata fields exposed in the gateway output (for example
description, tick_size, and any MM policy fields configured by the engine).
Checkpoint: you can explain how SYMBOLS complements config-file inspection during operations.
Order Lifecycle Summary¶
stateDiagram-v2
[*] --> NEW : accepted
NEW --> PARTIAL : partial fill
NEW --> FILLED : full fill
NEW --> CANCELLED : cancel/expire
PARTIAL --> FILLED : remaining filled
PARTIAL --> CANCELLED : cancel remainderReflection¶
Why does the operator's KILL|GW=<gateway_id> cancel every order for an entire gateway
rather than requiring one CANCEL per order? In what operational scenario
(think: a runaway bot or a disconnected trader) does that bulk-kill behavior
matter most?
Further Reading¶
Next: 09 — Market Making