How should pending orders be cancelled or replaced safely?

Why this matters

Production automation must remain predictable when markets move fast, messages duplicate or reorder, accounts differ, orders partially fill, or infrastructure restarts. The goal is observable state—not merely “an alert usually opens a trade.”

End-to-end model

Pine decision
→ TradingView alert
→ authenticated webhook
→ freshness / duplicate / schema validation
→ NRUNO account + symbol routing
→ cTrader operation
→ broker result
→ position reconciliation
→ user-visible status / audit log

Real-world scenarios

Scenario A — Move pending entry

Record the UTC timestamp, signal/order ID and intended action. Compare the TradingView event, webhook/NRUNO state, cTrader result and final position. The evidence should show which stage changed the intended action into the observed result; apply the documented resolution only to that stage.

Scenario B — Cancel invalid setup

Record the UTC timestamp, signal/order ID and intended action. Compare the TradingView event, webhook/NRUNO state, cTrader result and final position. The evidence should show which stage changed the intended action into the observed result; apply the documented resolution only to that stage.

Scenario C — Replace pending

Record the UTC timestamp, signal/order ID and intended action. Compare the TradingView event, webhook/NRUNO state, cTrader result and final position. The evidence should show which stage changed the intended action into the observed result; apply the documented resolution only to that stage.

Deep diagnostic workflow

1. Freeze evidence before changing settings.
2. Establish intended action and valid time window.
3. Prove what TradingView knew at trigger time.
4. Verify message identity, authentication, freshness and ordering.
5. Verify resolved account, symbol, volume and command.
6. Read exact cTrader/broker response.
7. Reconcile requested volume with actual position state.
8. Apply the documented failure policy.
9. Reproduce on demo.

Design rules

• Explicit action/unit/account/symbol/position/expiry beats guessing.
• Current cTrader state beats assumed state.
• HTTP success, connector acceptance, cTrader acceptance and final fill are separate.
• Entry filters and risk-reducing exits need separate policies.
• Duplicate handling must be idempotent.
• Stale signals need expiry.
• Never silently convert an invalid command into a different trade.
• Exact errors belong in logs and user-facing diagnostics.

NRUNO implication

NRUNO is the execution connector, not the signal generator. It should expose validated command state, authorized routing, duplicate/stale handling, cTrader connectivity, exact execution errors and a traceable audit history. Support cases can then become anonymized Wiki scenarios.