Arnold Holm

How does the Pine v5 adapter expose the feed: a TradingView-supported ticker for request.security, or values prepared elsewhere? I would need the symbol identifier, timestamp convention and reconnect replay behaviour before comparing Python and chart backtests. One small sample of the same timestamped bar on both paths would make the integration easier to check.

Your 912-to-163 example separates effect size from certainty well. One extra check I would keep is the anchor offset: repeat the non-overlapping selection for each feasible starting offset, then show the range of edge estimates rather than choosing the best offset. A single 30-minute grid can accidentally select favourable observations. This is a sensitivity check, not a set of independent tests.

One timing check I would add: moving WebRequest to OnTimer does not make it asynchronous. The same EA still waits for the response, so its local position management can be delayed too. I would test a deliberately slow API with a bounded timeout, then check how long management pauses and whether stale instructions are rejected when the response finally arrives. Broker-held stops and a local trailing rule are different protections during that pause.

For your busy-polling test, I'd also record quote age when the application makes its decision, not just request-response latency. A fast response can still carry a price that waited in a queue. Replay a burst at a fixed input rate and compare the oldest quote used, dropped messages and CPU before and after the change.

For the slow-session replay, I would also check what the client displays after it skips intermediate book updates. Give each replacement snapshot a sequence marker and an explicit fresh/stale state, then test an old queued delta arriving after that snapshot. A fast fan-out can still leave one screen wrong if it accepts that old delta.

Your updated OnInit now seeds the current bar, so attaching midway through a candle waits for the next bar. One further negative case is a new bar whose CopyBuffer values are not ready yet. If the helper advances lastBar before a successful read, that closed-bar evaluation can be lost. I would advance the processed-bar marker only after the required values are available, keeping entry deduplication separate.

One order-sensitive example is a signed webhook. I would verify the signature against the original request bytes before using the JSON as trusted input. Express’s JSON parser has a verify(req, res, buf) hook for that; re-stringifying req.body can change whitespace and break the signature. Then validate the fields before the route performs any action. Three useful checks are: a valid signature succeeds, one changed byte fails, and malformed JSON reaches the error handler without triggering the action.

UTC storage helps, but I would also retain the original timestamp, source timezone and offset. During the autumn clock change, the same local 01:30 can occur twice. Reject an ambiguous timestamp until the offset is known instead of silently choosing one. I would also keep the candle session boundary separate from storage time: a UTC calendar day and a broker trading day can produce different daily highs and lows.

A 10Gbps NIC alone cannot prevent UDP loss. A burst can still overflow the receive ring or socket queue if the consumer falls behind. I would record feed sequence gaps and queue drops under the same burst replay, then stop new orders until a snapshot or replay restores the book. That separates a latency problem from trading on an incomplete order book.

Self-hosting is useful, but I would still limit each key to the permissions the bot needs, with withdrawals disabled. For the fan-out layer, one test would disconnect a worker while the publisher keeps sending ticks, then reconnect it. The worker should detect the gap, rebuild its state from a snapshot, and keep new entries disabled until that state is current. Redis Pub/Sub alone does not replay the missed events.