NRUNO Trading Automation Wiki · Question 65

Which cTrader errors should never be blindly retried?

Infrastructure, Cloud & PerformanceLast reviewed: 25 Aug 2026
Short answer

Do not blindly resend deterministic rejections such as BadVolume, UnknownSymbol or InvalidStopLossTakeProfit. Repeating an unchanged invalid request adds load and can create unpredictable behavior if account conditions change later.

What this means in practice

Do not blindly resend deterministic rejections such as BadVolume, UnknownSymbol or InvalidStopLossTakeProfit. Repeating an unchanged invalid request adds load and can create unpredictable behavior if account conditions change later. This page is specifically about “Which cTrader errors should never be blindly retried?”, so each scenario below is explained by its own mechanism instead of sharing one generic diagnosis.

Real-world scenarios

Scenario A — BadVolume

Compare requested size with the cTrader symbol minimum, maximum and step. Convert to one canonical internal unit, normalize once, and log requested versus submitted volume. For Scenario A — BadVolume on question 65, use that evidence specifically to answer “Which cTrader errors should never be blindly retried?”; keep it separate from the evidence for the other scenarios on this page.

Scenario B — UnknownSymbol

Inspect the mechanism named by “Scenario B — UnknownSymbol” directly. Record its input, the state immediately before it and the first observable output that differs from the intended result. For Scenario B — UnknownSymbol on question 65, use that evidence specifically to answer “Which cTrader errors should never be blindly retried?”; keep it separate from the evidence for the other scenarios on this page.

Scenario C — InvalidStopLossTakeProfit

Inspect the mechanism named by “Scenario C — InvalidStopLossTakeProfit” directly. Record its input, the state immediately before it and the first observable output that differs from the intended result. For Scenario C — InvalidStopLossTakeProfit on question 65, use that evidence specifically to answer “Which cTrader errors should never be blindly retried?”; keep it separate from the evidence for the other scenarios on this page.

Scenario D — NoMoney without state change

Read free margin, leverage and existing exposure at submission time. NoMoney is an account-state rejection; retrying the identical order without a state change is not meaningful. For Scenario D — NoMoney without state change on question 65, use that evidence specifically to answer “Which cTrader errors should never be blindly retried?”; keep it separate from the evidence for the other scenarios on this page.

What to check

  • target connector/account identity
  • exact broker symbol
  • normalized order parameters
  • cTrader response and final position/order state

Practical rule

For “Which cTrader errors should never be blindly retried?”, change only the first layer whose evidence no longer matches the intended action. Preserve signal identity, timestamps and final cTrader state, and reproduce execution-affecting changes on demo before live use.

Decision summary

Direct answer: Do not blindly resend deterministic rejections such as BadVolume, UnknownSymbol or InvalidStopLossTakeProfit. Repeating an unchanged invalid request adds load and can create unpredictable behavior if account conditions change later.

Next action: Match the observed evidence to one scenario above, test that mechanism independently on demo and keep the result traceable with one signal ID.

Primary sources

Need a TradingView → cTrader execution route?

NRUNO routes your TradingView instructions to cTrader. Your strategy and signal logic remain yours.