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.
orderis 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.