Merging a Looser Exit Rule - Sorting Real Failures from Pre-Existing Ones After a Restart
A looser exit-timing rule and a round of paper-broker fixes landed on the same day, followed by a resident restart. The full test suite then turned up some failures, and each one had to be checked against the merge before trusting it.
This is the English version of a post originally written in Korean for my algorithmic trading system devlog(new tab).
Yesterday's buy freeze lifted itself this morning
Yesterday, the account's assets dropped far enough below their peak that a safety mechanism kicked in and froze new buying.
This morning, the system checked that assets were actually up versus yesterday's close and lifted the freeze on its own. Had the number gone the other way — closer to the line where it would have forced a full liquidation instead of just pausing buys — this would have been a much tenser morning to watch.
Loosened the exit-timing rule
A research thread that had been running for several days reached a conclusion today.
Instead of exiting a holding as soon as its rank slipped even a little, the rule now lets it ride longer. A separate mechanism that force-closed positions purely based on how long they'd been held got retired at the same time.
This conclusion went through two rounds of checking. A backtest on historical data confirmed the direction first, then real fill data was used to re-check it.
Only after confirming that real-world buy-side friction (the rate of orders that simply don't fill) was worse than the backtest suggested, and adding a monitor to watch that friction going forward, was the change finalized.
Also today: paper-broker fixes merged in
A separate improvement to the paper-trading broker landed the same day.
It fixes a case where the system failed to recognize market holidays correctly, and closes a gap where reconnecting to the exchange after a dropped connection could cause an order ID to be processed twice. A fix for keeping holdings consistent across stock splits went in alongside it.
This code went through two rounds of independent review by a separate AI. The first round's findings were addressed and sent back for another look; a second-round finding — that rerunning a rejected operation could throw off the average cost basis on holdings — was fixed before the merge went in.
Restart, then re-checking with tests
After market close, six resident processes were restarted together to pick up today's merges.
The restart itself went smoothly. Running the full test suite afterward turned up a handful of failures and a dozen or so errors.
The first instinct was to suspect the merge. The check was simple: roll back to the pre-merge state in a separate workspace and run the same tests there.
The same failures reproduced in that pre-merge workspace too — meaning they predated today's changes and had nothing to do with them.
The dozen-odd errors turned out to be an environment artifact: the test run took over an hour, during which resident processes touched observation files the tests were watching. Each real failure got noted separately to be fixed later, independent of today's merge.
Sticking to that order — check whether a failure is actually caused by your change before reverting anything — meant today's merge stayed in place.