Pending orders
Use execution snapshots and local guards to avoid duplicate requests.
An accepted order can remain pending. Your next strategy invocation must account for it before deciding to submit another entry or exit.
Read before acting
The SJS example awaits context.getOrders() and context.getPositions(), verifies that both results are arrays, and waits if any order exists. If order inspection is unavailable, it waits rather than assuming an empty order list.
That conservative guard belongs to a single-instrument walkthrough. A broader strategy needs explicit ownership and matching rules for the orders it is responsible for.
Guard asynchronous work
The crossover uses a local busy flag while it awaits execution reads and submits a request. It also consumes an observation timestamp once, avoiding repeated submissions for that timestamp.
These controls solve local duplicate evaluation. A state read is not an atomic lock across other apps, browser actions, or independent processes sharing an account. Runtime duplicate checks also have a narrower meaning than durable idempotency.
Explain why an order remains pending
Check market-time fill delay, qualifying quote, price thresholds, capital, trade limits, and the selected runtime. In replay, no additional wall-clock waiting creates a market observation that is absent from the dataset.
A submitted order can also fill immediately. An empty pending list after submission can mean completion, cancellation, rejection, or stale reporting; reconcile it with positions and trade records.
Define what happens to a blocked signal
The sample consumes its crossover before discovering a pending order. It will not retry that crossover merely because the pending order later disappears.
A different strategy can maintain a desired action until it is satisfied, but that requires explicit expiration, revalidation, and retry rules. Avoid turning every new frame into an unconditional repeated request.
Continue with modifying and cancelling.