Skip to content

MngCancelTradesList

Description: Allows a manager to submit cancel requests for multiple open trades by providing a list of order IDs.

Warning

Only market BUY/SELL trades in TS_OPEN_NORMAL, TS_OPEN_REQUEST or TS_OPEN_RESTORED can be cancelled.

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.

Batch responses use the existing per-order failures collection. A policy rejection is serialized with error: "PERMISSION_DENIED"; the handler discards the specific copy-policy error code and message for this item. It is therefore not reported as COPY_MANUAL_TRADING_DISABLED or COPY_COPIED_ORDER_MANUAL_FORBIDDEN in the batch response. Account/order access is checked first, and the batch continues processing independent items.

The top-level command status remains 200 when all requested orders are accepted, 207 when the result is mixed, or 409 when no order is accepted. These are aggregate statuses; a policy rejection does not make the batch all-or-nothing.

Request Parameters

Name Type Required Description
orders array Yes List of trade order IDs to cancel (integers)
__access object Yes Access object containing session type information

Request Example

{
  "orders": [1001234, 1001235, 1001236],
  "__access": {
    "type": 1
  }
}

Response Parameters

Name Type Description
rows array Successful cancel acknowledgments
matched integer Total number of requested orders
cancelled integer Number of orders accepted for cancel processing
failed integer Number of orders that failed validation or enqueue
failures array Optional per-order error details for failed cancel requests

Response Example

{
  "rows": [
    {
      "accepted": true,
      "order": 1001234,
      "state": 9
    },
    {
      "accepted": true,
      "order": 1001235,
      "state": 9
    }
  ],
  "matched": 3,
  "cancelled": 2,
  "failed": 1,
  "failures": [
    {
      "order": 1001236,
      "error": "RET_NOT_FOUND",
      "message": "Trade not found"
    }
  ]
}

Notes

  • A successful response is an acknowledgment that the cancel request was accepted, not confirmation that the open trade is already cancelled.
  • order is the correlation identifier for subsequent trade lifecycle events.
  • If no orders are accepted, the method returns 409.
  • If some orders are accepted and some fail, the method returns 207.

Atomic admission

Each ticket uses the same atomic live-state check and request reservation as MngCancelTrade. Closed history and tickets already undergoing another mutation are included in failures, not rows. Repeated or overlapping lists cannot admit a second cancellation for the same reserved ticket. Per-order runtime errors use the mapped error code (for example RET_ERR_CANCEL) and message. A wholly rejected list returns 409; a mixed list returns 207.