I moved the safety-window math I'd been doing by hand into code, and also fixed a live-account trade that got reversed right after it went through
This is the English version of a post originally written in Korean for my algorithmic trading system devlog(new tab).
Today I kept getting stuck trying to run a GPU experiment to evaluate a new local model candidate.
The first attempt died immediately because the runtime environment was missing a required program path. The second attempt died too, running under the wrong Python environment that didn't have a needed library.
After fixing both bugs, I finally got the experiment running on the third try — and then a different problem showed up. Near the end of regular trading hours, the experiment's run window overlapped with the daily settlement window, and the experiment quietly stopped processing new tickers on its own.
The stop itself was working as designed. A safeguard that blocks new work from starting during the settlement window did exactly what it was supposed to do.
The problem was that I didn't notice for a while. The experiment logged itself as "done," so at first I thought it had finished — only to find, on closer inspection, that it had stopped after covering less than a third of the tickers.
Moving hand-calculated math into infrastructure
Looking at the failure pattern, there was a common thread. Every time, figuring out the safe run window meant manually calculating the start time and the time limit by hand.
Miscalculating or forgetting that math accounted for more than half of today's failures. So I decided to move the calculation itself into code.
I built a shared function that answers "how much time is left until the next risk window" and "would starting now finish safely," and wrote a new standard launch script that runs experiments through this function to compute the time limit automatically.
I also settled on a format for recording how far an experiment got if it stops partway, so it can resume from there. Going forward, a time-window collision like today's shouldn't require anyone to do the math by hand to recover safely.
Fixed a live-account trade that reversed itself
Separately, another issue turned up on the live account today: a position that had just been topped up got sold back off again shortly after.
At first it looked like a delayed order fill causing a temporary anomaly. But handing the investigation to another AI for a second opinion showed that diagnosis was wrong.
The real cause was structural: in the band-based buy/sell logic, the top-up buy was landing too close to the boundary between bands. Even a tiny price move was enough to cross the boundary and immediately trigger a sell signal.
Once I confirmed the cause, I widened the margin around that boundary check. It's the same kind of margin the regular buy side already had — now applied to the top-up side as well.
The fix was in place before the next trading day started.
The two problems today look unrelated, but they taught the same lesson. Whether it's a time window or a price band, logic that sits right up against a boundary breaks easily from the smallest error or fluctuation.
Since the boundaries themselves can't go away, today's fix for both was simply to give them more margin.
Top comments (0)