5-C)

Dear user, this chapter introduces three advanced capabilities: data snapshots before strategy execution, startup access control before market opening, and reconciliation and logging during long runs. If you haven’t yet successfully run the basic Live application, please read Simulated trading platform: configuration and operation first.

What problem does this chapter address? Minute-level strategies that repeatedly pull data at every step are slow and prone to missing market data; placing orders before the market opens without proper configuration or data carries significant risk. We’ve made these checks configurable and logged them for easy review.

Internal code name mapping (used by maintainers/smoke documents)

In the evolution of qteasy live, 5-A / 5-B / 5-C refer to three capabilities: policy snapshots, activation access control, and long-term observability, respectively. Smoke documentation and maintainer’s notes will use codenames; as a user, you only need to remember the “user-directed name” on the right. The table below establishes the correspondence between the codenames and common usage—when reading the rest of this chapter, you can understand “5-B” as “activation access control.”

Meaning of each column: Code is the internal stage number; User-assigned name is the recommended name in the documentation; One sentence indicates the position of this capability in the live pipeline.

How to use: When you see codes such as 5-A in the main text, refer to this table; see the configuration key name in Simulated trading platform: configuration and operation §4 “Policy Snapshot” “Start Access Control” line.

code name	User name	In short
5-A	Strategy Snapshot	Data is pre-fetched before the strategy runs, and this step reuses the data to reduce redundant I/O.
5-B	Activate access control	Before opening/running, check the readiness status; if it fails, an alarm or block should be triggered.
5-C	Long-term observable	Order mapping with brokerage account, risk log rotation, reconciliation and diagnosis of orders in transit

5-A: Strategy Snapshot

You can think of it as follows: Before each “exam,” prepare the test paper and materials on your desk; when you’re actually answering the questions, you no longer need to rush to the printing room.

When live_trade_split_strategy_prepare=True, qteasy will insert a prepare_strategy_snapshot task before each run_strategy scheduled time (the lead time is controlled by live_trade_prepare_lead_seconds; 0 means enqueuing at the same time, but the order still guarantees that prepare is first).
The prepare_strategy_snapshot function completes the heavy lifting that was done before run_strategy: refreshing sub-day frequency data, preparing data buffers, updating live prices, and injecting process data; after completion, it leaves a “snapshot valid” marker in memory (trading day + step number + time).
Subsequently, if run_strategy finds that the snapshot is still within live_trade_strategy_snapshot_max_age_seconds and the step number is consistent, then the above fetching will not be repeated; otherwise, snapshot_missing / snapshot_stale is recorded and this step’s strategy is skipped (to avoid using expired data to calculate signals).
When split is enabled, prepare_strategy_snapshot and run_strategy are executed synchronously on the main thread (separated from asynchronous live pricing tasks), avoiding multiple threads from simultaneously accessing the Operator.

Differences from actual behavior: Snapshots are in memory and need to be prepared again after the process restarts; they are not permanent caches on disk.

5-B: Start the access control (run_startup_gate)

You can think of it as: a safety check before departure – whether the strategy is ready, whether the necessary data tables are available, and (optionally) whether the local ledger is consistent with the brokerage’s end.

live_trade_startup_gate_mode:
- off — Turn off access control
- warn — Failures are only logged/traced, but transactions are still allowed (recommended for gradual rollout first).
- block — rejects if it fails. run_strategy is then queued (skip_reason=gate_failed).
Trader will invoke the access control after generating the daily schedule (non-trading days are quickly skipped).
Check the layering (failure codes will be written to the trace ``failures`):
- L1: Is the Operator ready? Does the account exist?
- L2: Whether the main history table is in the data source (mapped to daily frequency table by asset_type, etc.)
- L3 (Optional): If the Broker returns a non-empty remote cash/position, compare it with the local one; do not perform a hard comparison if the remote API is not implemented.

For a complete list of manual smoke-live grid roads, see Simulated live trading manual smoke generation solution (live_grid_multi).

5-C: Ledger, Logs, and Recovery Observability

Above 5-A/5-B, it facilitates long-distance troubleshooting and auditing (excluding automatic order modification/compensation; actual QMT remote querying is a later version):

Order ↔ Broker ID Mapping: Upon successful acceptance, broker_order_id / broker_name will be written back; if the order is rejected, rejected will be written back and the broker field will be empty.
Log Rotation Extension: rotate_trade_logs cleans up expired *.risk.log in addition to trade CSV (see Product list and troubleshooting for rules).
Reconciliation and Diagnosis Trace:
- The pre_open and post_close commands output the reconcile checkpoint (e.g., checkpoint_passed, checkpoint_warn).
- DEBUG task ``diagnose_pending_orders`: Read-only comparison of local and remote pending orders.

Conclusion for beginners: Two types of “order rejection”

In the live order process, “rejection” can occur at either the RiskManager review desk (risk control) or the Broker processing (counter), where the evidence is located in completely different places. The 3-risk-and-order-lifecycle documentation has already explained this from a process perspective; the table below provides a comparison between the order table and the broker_order_id for quick troubleshooting.

Column Meanings: Path indicates order rejection/success type; Local Order Table indicates whether a new row has been added; broker_order_id indicates whether a write-back is required; Audit indicates the file or table that is recommended to be opened first.

How to use: CLI shows a risky rejection reason and no new orders → first line; order list shows “rejected” and broker number is empty → second line; broker number exists → third line, then check the transaction status.

Example: risk_log contains ``<RISK REJECTED> Furthermore, if there are no corresponding new orders in the “orders” section, the order will be rejected by risk control. Do not check the brokerage’s connection information.

The path	Local order form	broker_order_id	audit
Order rejection due to risk control	Not put into storage	—	*.risk.log + ``<RISK REJECTED> ``
柜台受理拒单	There is a line, `rejected`	null	Order form + trace
Application Successful	submitted etc.	Write Back	Order form + trace

diagnose_pending_orders output fields (brief)

local_pending_count — Local pending count
``remote_pending_count` — Odd number of remote pending requests (simulator is usually empty)
local_pending_without_broker_order_id — Local orders submitted but lacking broker ID
local_pending_missing_remote — A brokerage account exists locally but not remotely.
remote_pending_not_in_local — Mapped on the remote end but not on the local end.

CLI and DEBUG (Operations and Maintenance)

Trader Shell (–ui cli) commonly used commands (help is in English):

gate / startup-gate — Manually run the gate control startup process.
reconcile / snapshot-reconcile — Reconciliation JSON
run –task diagnose_pending_orders — Diagnose pending orders (requires DEBUG)
artifacts / ls-artifacts — Four-bond artifact path
rotatelogs / rotate-logs — Manual log rotation
broker status|connect|disconnect — Brokerage session (simulator is the flag)
sync / pull-state — Reserved, real remote synchronization has not yet been implemented.

Recommendations for the next trading day

5-A: Are there too many strategy_run_skipped entries in the trace? Is the live price frequency not lower than the strategy step frequency?
5-B: First use warn to check gate_warn / gate_failed; then use CLI gate to verify before trying block.
5-C: Closing the market with reconcile and diagnose_pending_orders; if necessary, rotatelogs –days N to verify risk cleanup.