Recurring Toss Token Revocations - A Restart-Order Mismatch
Tracked down why an external quote API's auth token kept invalidating itself, and decided to wait for the final verdict on a new-exchange entry experiment despite failing one criterion early.
This is the English version of a post originally written in Korean for my algorithmic trading system devlog(new tab).
The token revocations came back
For the past week or so, every time the resident processes got restarted, the auth token for the external quote API would start invalidating itself.
It happened once earlier this week, then stayed quiet for two days.
Then early this morning the revocation logs started pouring in again — steadily, every five minutes.
The cause was restart order
Lining up this recurrence against the earlier one, both shared the same pattern: one of the two resident processes had been restarted while the other was left on its previous run.
Each process requests its own fresh token on startup. If one process jumps to a new generation while the other stays on the old one, each keeps invalidating the token the other just issued — a tug-of-war.
The fix seemed obvious: bring both processes onto the same generation. So the lagging process got restarted too.
Right after that restart, the last revocation log appeared and then nothing — two more five-minute checks came back clean. One more day of monitoring before calling it fully resolved.
This token only feeds price lookups, not the order path itself, so none of this ever touched live trading. But it's now clear that restarting the two processes separately causes this side effect, so future restarts need to keep them in lockstep.
New-exchange entry experiment: failing one bar, but waiting for the final call
A multi-week experiment validating order entry on a newly opened exchange hit a snag at its interim checkpoint — it failed one of the criteria.
The criterion checks whether enough order-book depth is sitting at the price level when an order goes in. Running the numbers, even a perfect run for the remaining days couldn't pull this criterion back into range. It's effectively a confirmed fail.
The question was whether to kill the experiment now or stick with the originally scheduled final verdict date. Another AI tool was asked for its read on this.
Its answer: wait. The experiment wasn't only testing this one criterion — it's also collecting evidence for a separate open question, and that answer only becomes available on the final verdict date.
Taking that advice, the plan is to wait for next week's scheduled final verdict as planned. The failed criterion and the still-unanswered question will be written up separately in the final report.
One-share test fee reconciliation pushed to the next deposit cycle
Yesterday's planned one-share buy-and-sell test on the live account executed cleanly today.
It's a small test — buy and sell at the same price to isolate exactly what fees get deducted — but confirming the actual fee and tax amounts only becomes possible once the deposit lands and goes through ledger reconciliation(new tab).
While checking on that, it turned out another small test from last week was still sitting with its deposit reconciliation unfinished. Both reconciliations are now bundled to run together on the next deposit date.