Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A trading bot can apply a guard exactly as coded and still miss the risk it is meant to control. In a case described by Valerii Sakara, a MetaTrader expert advisor checked open positions but not pending orders, and a purported daily-loss limit used the bot’s startup balance instead of resetting each day. The account is based on static code review, not a reproduced run; the project is unnamed.
How pending orders slipped past a one-trade guard
The entry logic returned when it found an open position. But a pending sell-limit order is not an open position until it fills. Sakara reported that the reviewed code did not count resting orders, leaving a gap between what the guard checked and what could become exposure.
The bot also had a cooldown of about one minute, while signals could recur on a one-minute chart. That pause was not a substitute for checking whether an earlier order was still waiting. Repeated signals could place multiple pending orders before any filled. Although each order was sized against the stated per-trade cap, independently sized orders could create simultaneous exposure above that single-trade cap if several filled.
These are the author’s reported findings, not independently reproduced test results. The design lesson is to count every state that can create exposure—not just positions already open.
#1 Best Overall
Inventory every exposure-bearing state
- Open positions.
- Pending or resting orders.
- Orders submitted but not yet confirmed or otherwise in flight.
- Partial fills, including any unfilled remainder that is still active.
A guard that checks only one category cannot constrain the others. The condition may be correct for positions and still fail to enforce a limit across all active risk.
Why a “daily” loss limit may not be daily
The second reported issue was not the comparison between the starting and current balances. It was when the starting balance was captured: at process launch, with no reset at a new calendar day. As described by Sakara, the result behaved like a since-start loss limit. Once tripped, it remained in effect until a manual restart.
“Daily” needs a defined clock and reset rule. Process launch, server-day rollover, and a manual reset are separate events. A risk policy should specify which one establishes the baseline, what time zone or server day applies, and what action is authorized if the limit has already tripped.
What should happen when the limit trips?
Blocking new entries does not necessarily remove existing exposure. Sakara reported that the original loss-limit behavior stopped new orders but did not cancel resting orders, which could still fill after the bot was supposedly halted.
A complete trip response must say what happens to both future actions and orders already in the market. In the reported pull request, the proposed change cancels resting orders when the daily limit trips. That is a report about a pull request, not confirmation that a deployed release contains the change.
What the reported pull request changed
Sakara reported that the maintainer publicly confirmed both issues and opened a pull request about seven weeks after the issue was filed. The reported proposal would allow one resting sell-limit order at a time, cancel an unfilled order after a configurable expiry (30 minutes by default), reset the daily starting balance when the server day rolls over, and cancel resting orders when the daily loss limit trips.
Those details describe the reported proposal; they do not establish which release, if any, shipped it. A pull request is not proof of behavior in a particular deployed version, so anyone relying on a guard should inspect the applicable code or verify the release directly.
Free tools Windows power users keep installed
One-click scans. No signup required.
How to review and test a guard
Review the guard’s scope as well as its predicate: ask what exact population the code counts, and whether anything outside that list can still create risk. Then test the blind spots with known-good and known-bad scenarios rather than treating a normal entry path as sufficient evidence.
- Repeat a signal before the first order fills. Confirm that another signal cannot create an additional resting order when the policy allows only one.
- Cross the defined day boundary. Keep the process running through the rollover and check that the loss baseline changes at the intended time—not merely at launch.
- Trip the limit while an order is resting. Check that new entries are blocked and that existing orders receive the policy’s intended treatment.
- Check recovery explicitly. Determine what event, if any, permits trading to resume after a trip, such as a new day or an authorized manual reset.
- Include negative controls. Verify that cases which should not trip the guard remain permitted, as well as checking that known limit violations are caught.
The scenarios above are recommended tests; Sakara’s account does not say that they were run. The general verification principle is to test both known-bad and known-good inputs and use negative controls, rather than infer correctness from the presence of a guard.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
