In n8n, a leading `=` marks a field as an expression, and interpolating a variable inside it still needs `{{ }}` around the reference. The swing bot's close-position step sent an order body of `"=$json.ticker"` with no braces, so the broker received the seven literal characters `$json.ticker` as the instrument and rejected the order, every time, for months [4].
That is an ordinary templating mistake with an ordinary blast radius, right up to the two flags on the node. `onError: continueRegularOutput` and `alwaysOutputData: true` mean the node hands an item to the next step even when the call failed, and the workflow continues down its success path [5]. The Discord step downstream tested nothing about a fill. An item arrived, so it posted "Position Closed", and it did that hundreds of times [6]. The author's own verdict on this is worth keeping: an error handler that swallows the error and continues is a machine for manufacturing false confidence [15].
Three other failures in the same system share one shape, which is a value computed and never consumed. The safety node calculated `circuitBreakerTriggered` and `pauseReason` on every run, no downstream node referenced either, and all four rules were unreachable code [8]. A second bot's breaker read its state file off an NFS mount with `cat ... 2>/dev/null`, so a dead mount returned empty and the breaker failed open [11]. The "autonomous trader" was handing qwen2.5:7b roughly 2.4 KB of copy-pasted JavaScript in place of a prompt, which is why the model never saw the research, the portfolio, or the cash balance [9]. Its only limits were `amount > 0` and `amount <= cash`, applied per trade rather than in aggregate, so five proposals could each spend all the cash [10].
Then the arithmetic on the one bot that was actually trading. It carried no target allocations and no drift thresholds; it took the LLM's suggested amounts, kept only their ratios, pro-rated those across all free cash, and sold a whole position to raise that cash first [12]. The cron was meant to be weekly and ran every weekday at 07:30 [13]. Five weekday runs against one intended run is five times the liquidation frequency [16].
None of this was visible from inside the pipeline, because the pipeline's only evidence of a sale was the output of the node that attempted it. The evidence that mattered sat on the broker: April and May positions still open in July, with the comforting "+£324 unrealised gain" attached to two stocks the bot was structurally unable to sell [7]. Realised P&L on the demo account was -£424 [2]. The live account held £4.83 and had seen no bot-initiated trade in months [3].
Reading back is a second integration, not a config change. After each order you query fills or positions, diff them against the intent that produced the order, and let the notifier speak only from the broker's answer. That buys an extra API call per trade, a stored representation of intent, and somewhere for mismatches to land. What it removes is the ability to generate a green tick by merely continuing to execute.
The figures here are one person's account and transfer nowhere [1]. The mechanism transfers under one condition: your success notification is built from the output of the call rather than from the system of record. Had the Discord message been rendered from a positions query, this stays a rejected order in a log. As supplied, the writeup breaks off while describing the rebalancing bot and contains no implemented verification layer, so what it documents is the diagnosis [18].
