MngCancelTrade

Description: Allows a manager to cancel an open market BUY or SELL trade by its order ID.

This method follows the common Trade Request Lifecycle. A successful response means the cancel request was accepted into runtime processing.

Warning

This method only cancels market trades in TS_OPEN_NORMAL, TS_OPEN_REQUEST or TS_OPEN_RESTORED. Use the pending-order cancellation command for pending orders.

Access Control

Requires dealer_trades for manager/dealer sessions. The target account must also match the manager groups and brand scope loaded from the cached manager record. Token payload is used only for manager id and session type.

Copy-Follower Manual-Write Checks

For SESSION_USER or SESSION_CUSTOMER requests, this mutation applies the copy-follower manual_trading_mode after the usual account/order ownership checks. The check applies only when the target account has an enabled follower profile. Mode 0 rejects all manual writes; mode 1 permits new or non-copied orders but rejects changes to linked copied orders; mode 2 permits both. Manager/admin/dealer staff sessions bypass this follower policy.

HTTP	Error	Message
403	COPY_MANUAL_TRADING_DISABLED	Manual trading is disabled for this copy follower
403	COPY_COPIED_ORDER_MANUAL_FORBIDDEN	Manual changes to copied orders are disabled for this copy follower

The command returns the denial for its target login or order without accepting that mutation.

Request Parameters

Name	Type	Required	Description
order	int	Yes	ID of the trade order to cancel
__access	object	Yes	Access object containing session type information

Request Example

{
  "order": 1001234,
  "__access": {
    "type": 1
  }
}

Response Semantics

If the request is accepted:

• the cancel request passed validation
• the order was accepted into runtime processing
• final trade cancellation is resolved asynchronously

The response should be treated as an acknowledgment object.

Response Parameters

Name	Type	Description
accepted	bool	Always true on successful acknowledgment
order	int	Order identifier being cancelled
state	int	Accepted request state, typically TS_CANCEL_REQUEST

Response Example

{
  "accepted": true,
  "order": 1001234,
  "state": 9
}

Lifecycle Notes

• The immediate response is an acknowledgment, not a final cancellation report.
• The trade should be tracked by order.
• Final resulting state is resolved later in runtime processing.

Atomic admission and invalid states

The live command and state are checked under the same trade-cache lock that reserves TS_CANCEL_REQUEST. Closed history, deleted records and orders already undergoing cancellation, close, partial close or update are not admitted. Repeated or concurrent requests cannot reserve the same cancellation twice; a rejection must leave the existing record and account finance unchanged.

For a visible record with an invalid command/state, the existing handler error format is:

{
  "extID": "cancel-1",
  "status": 401,
  "data": {
    "error": "CANCEL_TRADE_ERROR",
    "message": "Operation was canceled"
  }
}

extID echoes the TCP request identifier; status is the response code; data.error identifies the admission failure; data.message is the human-readable runtime error. Access and missing-record errors can be returned before this admission check. Successful data fields remain accepted, order and state as documented above.