DEV Community

finaltype
finaltype

Posted on Originally published at finaltype.github.io

"[Sep 10] Two Bugs on Account-Migration Day, Plus the Real Root Cause of the GPU Failure"

The physical share transfer went through, but the cash auto-sweep sat broken all day and a live account hit a reconciliation incident. Separately, the recurring GPU-detection failure finally got a real fix.

This is the English version of a post originally written in Korean for my algorithmic trading system devlog(new tab).

Migration day, and the auto-sweep sat dead all day

As decided last night, this morning I carried out the physical transfer of held positions from the old account into the new one.

The transfer itself went through cleanly and was processed without issue.

The problem was the cash auto-sweep logic I'd written the day before — code meant to automatically roll cash freed up by sells on the old account into the new account's trading budget. A field name was mismapped, so it never fired once, all day.

The core feature of migration day was silently dead. I found the cause and fixed it before the day was out.

A reconciliation incident on the live account

Right after the market closed this afternoon, the new account threw a reconciliation(new tab) alert.

Two bugs compounded. One: the logic that fetches account valuation only read the first page of a paginated response, and mistook an empty intermediate page for an actual zero balance.

Two: the end-of-day close was missing a step that reconciles the day's fills into the ledger before closing. So the last round's two buy orders never made it into the ledger before close ran.

Both got fixed today, and the missing fills were booked manually to restore consistency. The same close-time reconciliation step already existed on the other account — it had simply never been carried over to the newly migrated account's code path.

Finally found the real cause of the GPU-detection failure

Last week (see the Sep 8 post) I thought I'd fixed the GPU-detection failure. This week the same symptom came back.

Today, working with a different AI, I retraced the cause from scratch. The original hypothesis — power-saving mode as the culprit — was ruled out by direct measurement.

The real cause was something else entirely: the display manager occasionally crashes in this multi-GPU setup and restarts, and during that restart GPU access permission quietly shifted from the login session's account over to a different system account.

It sat in that broken state for hours before the next early-morning job tried to grab the GPU and failed outright.

Tonight I applied a real fix — restructuring the permission model to remove that race condition — and verified it with a controlled reboot. After reboot, I brought production back up for real, and unlike last time, the GPU-detection failure did not reproduce.

Also today

I started validating a minimum-holding-period rule meant to cut down on turnover, rolled out to both paper accounts first. After about ten trading days of observation, I'll decide whether to extend it to the live account.

Top comments (0)