12. Simulate the risk controls and Broker adaptation in live trading (dual-path)

This tutorial walks you through two complete paths to verify the key behaviors of S1.3 in a simulated live-trading environment:

Path A: asset_type='E' + simulator
Path B: asset_type='FD' + simulator

The goal is “run through + observe + verify,” not just to look at concepts.

12.1. 0. 教程目标

Get both paths (E and FD) working end-to-end
Manually trigger one order rejection and identify the cause
Observe the visible behavior of the partial-fill status transitioning from partial-filled to filled

12.2. 1. 前置准备

An already runnable Operator
Local data can support the runtime frequency
Live account parameters have been configured

It is recommended to first prepare a rule configuration that can “stably trigger order rejections” (e.g., a smaller per-order quantity limit) to make it easier to reproduce the experiment.

12.3. 2. 路径 A：E + simulator

Step 1: Set up the configuration

import qteasy as qt

qt.configure(
    mode=0,
    asset_type='E',
    live_trade_broker_type='simulator',
    live_price_acquire_channel='eastmoney',
    live_price_acquire_freq='15MIN',
)

Step 2: Start running

qt.run(op)

Step 3: Submit a test order and observe the feedback

Check whether a “submission successful” prompt appears
Watch for whether a risk-control order rejection prompt appears (in English).
Record an order ID (for later log comparison)

12.4. 3. 路径 B：FD + simulator

Step 1: Switch the asset-type configuration.

import qteasy as qt

qt.configure(
    mode=0,
    asset_type='FD',
    live_trade_broker_type='simulator',
    live_price_acquire_channel='eastmoney',
    live_price_acquire_freq='15MIN',
)

Step 2: Restart repeatedly and place orders.

qt.run(op)

Step 3: Verify behavioral consistency.

The FD path should be able to enter the live execution flow.
The way to observe rejection/submission/logs is the same as in the E path.
The same type of order should have consistent feedback semantics across the two paths

12.5. 4. 人工触发一次风控拒单

Temporarily set strict rules (e.g., a per-order quantity cap) and submit an order that exceeds the limit. You should see an English prompt similar to:

Order rejected by risk rule [MAX_ORDER_QTY]: order quantity exceeds limit

and the corresponding record can be retrieved in risk_log.

It is recommended to verify at least twice:

One rejection (confirm the rejection reason is visible).
One release (confirm the strategy can continue running)

12.6. 5. 观察订单状态变化

Focus on whether the following occurs:

submitted -> partial-filled -> filled

In a partial-fill scenario, the final status should be consistent with the cumulative filled volume.

If you see partial-filled staying unchanged for a long time, go back to the troubleshooting page and check the logs against the “status misunderstanding” playbook.

12.7. 6. 教程验收清单

Path E is runnable
Path FD is runnable
Can trigger and identify risk-control order rejections
You can locate the reason for the order rejection in the logs.
You can observe and understand status changes during partial fills.
Complete at least one full closed-loop verification of “order rejection -> parameter adjustment -> release”

12.8. 7. 下一步

Mechanism deep dive: live_trading/3-risk-and-order-lifecycle
Extend the broker: live_trading/4-broker-adapter-and-integration
Troubleshooting manual: live_trading/5-artifacts-and-troubleshooting

12.9. 8. 结果判定标准

After completing this tutorial, you should be able to answer the following questions independently:

Was the current order rejected by risk control, or was it submitted but not filled?
Why would an order remain in partial-filled?
Which log file should you check first, and which fields should you look at next?

If you can answer all three questions above independently, it means you already have basic troubleshooting skills for live scenarios.