A flag meant to stop one account from rebuying transferred-out stock turned out to be global, and it force-sold the same stock right after another account received it. Also finished building a new automation tool for performance tuning.
This is the English version of a post originally written in Korean for my algorithmic trading system devlog(new tab).
A do-not-rebuy flag hit the wrong account
Over the past two days I've been physically transferring stock positions from the old account into the new one.
When a stock leaves the old account, I set a flag on it meaning "don't buy this back" — the point being to keep the old account from re-acquiring something it just gave away.
Going through the logs this morning, I found that this flag wasn't actually scoped per account. It lived in a single file shared across the whole system.
Because of that, the trading logic treated any account reading this file as if the flagged stock should be excluded from its rankings — including the new account, which had just received that same stock and was supposed to keep holding it.
The damage was real. Within hours of receiving the transfer yesterday, the new account force-sold several of those positions.
That's the exact opposite of what the transfer was supposed to do — move the assets over so the new account keeps managing them.
After this morning's second transfer, I confirmed the same risk was still sitting there and immediately cleared the flag file entirely.
The old account, it turned out, already had a separate safeguard in place (a mode that blocks all new trading), so the flag was never even necessary there — it was a redundant safety measure on one side that turned into a real bug on the other.
I haven't done the deeper fix yet — scoping the flag per account. If the transfer logic sets this flag the same way again next time, the same incident could repeat, so I wrote up two candidate code changes and left the decision for later.
A couple of ledger reconciliation slip-ups
Around midday, while checking on the transfer progress, I miscalculated total assets under management.
Going off ledger(new tab) values alone gave a number that didn't match the actual broker balance. It turned out there had been a real cash withdrawal from the account — bank withdrawals are outside what the system can detect automatically, so it never made it into the ledger.
A similar slip happened again in the afternoon, this time a personal withdrawal on the other account. Same fix: book it into the ledger to restore consistency.
Neither was an actual loss or trading error — both were just corrections to bring the ledger back in line with reality. Still, it reconfirmed a lesson: never trust the ledger alone when asked "what's the total," always cross-check against the actual broker balance.
Built a new automation tool for performance tuning
This project keeps swapping out LLMs and GPUs, and every time it does, performance tuning has to be redone from scratch.
Today I designed and built a tool to automate that whole process. After several rounds of back-and-forth with a different AI to refine the design, it landed on a loop: replay real traffic, search tuning parameters, verify the results, repeat.
The replay traffic is drawn from actual recent requests rather than synthetic load, and parameters that risk hurting output quality go through stricter verification than ones that are pure speed knobs.
I also split permissions so that the part of the system responsible for touching the GPU is separate from the part responsible for design — structurally preventing the design side from accidentally reaching into the live production service.
Today was just the build — I haven't run it once yet. The first real run is something I'll walk through myself next time.
Top comments (2)
Per-account scope is the key boundary here. I would make account_id part of the flag key and add a transfer regression covering the source, destination and a third account before enabling the fix. The broker-balance cross-check is a separate acceptance case, so keeping it outside the ledger-only test will make the failure visible.
Thanks — that matches exactly what I ended up shipping today. The exclude flag now carries a sleeve_id (our per-account key) set at registration time, and the reader filters on sleeve_id in (None, this_account) — so a flag registered for the source account no longer applies to the destination account. Legacy entries without a sleeve_id still fall back to global scope for backward compatibility.
I also added a regression test that reproduces the original incident directly: register an exclude for the source account, assert it applies there, and assert it does not leak into the destination account. Plus a separate test confirming the legacy (no-sleeve_id) behavior still works as before.
Good call on keeping the broker-balance cross-check as a separate acceptance case, by the way — that's actually a distinct bug from this one (a ledger-vs-broker mismatch from an out-of-band cash withdrawal), and I've been treating it as its own check rather than folding it into the ledger-only tests, for exactly the reason you gave.