Engineering note · Cloud take-profit state
Why cTrader Cloud Can Collapse an Advanced Take-Profit Ladder
Keep partial closes, trailing activation and restart recovery explicit when a cTrader cBot manages several take-profit stages in Cloud.
Buyer question
Why can several advanced take-profit targets behave like one target when a cBot runs in cTrader Cloud?
Failure pattern
Desktop-managed target instructions disappear, or trailing logic overwrites the one server-side position TP.
Acceptance rule
Every partial close and the active ladder stage are explicit, persisted and rebuilt before the next action.
A target ladder is a state machine, not a list of prices
A multi-stage exit often looks simple in a desktop interface. The trader sets three target prices, assigns part of the position to each target and enables trailing after the first one. That view can hide an important platform boundary. A position normally has one active server-side take-profit field. Extra targets may exist only as instructions managed by the running cBot or desktop process.
When the logic moves to cTrader Cloud, every stage that matters must be represented by code and recoverable state. The bot needs to know which target has already fired, how much volume remains, whether trailing is active and which action is allowed next. Three prices without those facts are not three durable exits.
The failure becomes especially visible when trailing starts. If the code treats the position-level TP as the whole plan, changing that field can make the remaining targets appear to collapse into one. The real defect is not the chart display. It is that two different responsibilities, the server-side protective level and the bot-managed partial-close ladder, were stored in one mutable field.
Source and public evidence
Separate the server TP from bot-managed stages
The server-side TP answers one question: at what price may the remaining position close if the platform can act without the bot? The ladder answers several other questions: which partial volume closes at each price, whether that stage already ran and what trailing may change. Keeping those models separate makes the behavior inspectable.
| Stage | Allowed behavior |
|---|---|
| OPEN | The full position is active. No partial-close stage has fired. |
| TP1_DONE | The first exact volume is closed once. Trailing may now become active. |
| TP2_DONE | The second exact volume is closed once while the remaining position stays owned. |
| FINAL_STAGE | Only the written final exit may close the remaining volume. |
| CLOSED | The position is gone and its persisted stage record can be retired. |
What the specification must freeze
- 1
Position ownership
Record the position identity, symbol and label that belong to this cBot. Foreign or manual positions stay outside the ladder.
- 2
Target prices
Give each target a stable index and state whether prices are absolute, pip-based or calculated from the confirmed fill.
- 3
Partial volumes
Write the exact normalized volume closed at each stage and the permitted remainder after the broker result.
- 4
Trigger rule
State whether crossing, touching or a completed bar activates a target and which Bid or Ask price is evaluated.
- 5
Trailing boundary
Define when trailing starts, what it may modify and whether the server TP remains, moves or is removed.
- 6
Persistence source
Name the stored fields and the reconciliation evidence used after a Cloud restart or reconnect.
Three acceptance tests
These cases test stage ownership, trailing independence and recovery. Run them with fixed position size, target prices and volume normalization so every observed result can be compared with one expected ledger.
Test 1
Exact volume at each stage
Input: Price reaches TP1, then TP2, while one position remains open.
Pass: Each target closes only its assigned volume once. The remaining size matches the written ladder after every stage.
Test 2
Trailing after the first partial close
Input: TP1 fires and the trailing rule becomes eligible while TP2 and the final stage are still pending.
Pass: Trailing changes only the permitted protective state. It does not merge, replace or silently cancel the remaining stages.
Test 3
Cloud restart after stage one
Input: The cBot restarts in Cloud after TP1 has closed but before TP2 is reached.
Pass: The bot reconstructs TP1_DONE, the remaining volume and trailing state before acting. It does not repeat the first close.
Handle broker outcomes as events
A requested partial close is not the same as a completed partial close. The stage should advance only after the platform reports the actual result. Rejection, normalized volume and a position that disappears for another reason need separate outcomes. Otherwise a retry can close the same stage twice or a failed request can be recorded as complete.
Recovery starts by reading persisted stage data and reconciling it with the current position. New target or trailing actions stay disabled until that comparison is complete. If the stored volume and live volume disagree, the cBot should expose the mismatch and stop the affected transition instead of guessing which stage occurred.
The event record should be small and boring: position identity, stage index, requested volume, confirmed volume, result code and timestamp. That is enough to distinguish a new target event from a replay of an old one. It also gives the acceptance test a receipt. A screenshot of three lines on a chart cannot prove that the second close happened once or that the same state returned after a restart.
Cloud execution also changes what can be observed during diagnosis. A developer may not have the same desktop panels or manually arranged chart objects. Log the stage transition and the reason for every no-action decision in platform-hosted output. Then one failed test can be traced from price input to state decision to trade result without assuming that the visual target list was authoritative.
Passing these tests proves the written exit lifecycle. It does not prove profit, favorable execution or future trading results. Strategy quality, broker conditions and Cloud availability remain separate questions.
Free next step
Write the stage ledger before writing the exit code
Use the free scope builder to record the target prices, partial volumes, trailing boundary, restart source and three pass cases. That gives a developer one deterministic Cloud lifecycle to quote and build.