Futures Trading v6.1.8

Release Date: August 13, 2026 Tags: MATCHING-ENGINE, RELIABILITY, HIGH-AVAILABILITY, LIQUIDATION, BUG-FIXES

Overview

A failover release, and the failure it fixes is silent. Only one process may run the matching engine, and it claims a lease to prove it. If the engine is killed hard — out of memory, a crashed thread, a kill -9, a server losing power — the lease row it holds does not disappear with it. It lapses about twenty seconds later.

A supervisor restarts the process immediately, because that is what a supervisor is for. So the replacement started inside that twenty-second window, was refused the lease, and came up as a read-only follower. The row lapsed seconds afterwards and nothing ever claimed it.

The result was a deployment with no matching engine at all — no order matching, no position marking, no liquidation — that looked completely healthy. The process was running, the API was answering, charts were updating. Only a restart that happened to land outside the window brought trading back. A follower now watches for the lease and takes over when it comes free.

Nothing a trader sees changes on a healthy deployment. Requires Core v6.6.5.

Update Instructions

pnpm updator

Restart the backend afterwards. Nothing to run, nothing to check, no database change.

Upgrade Notes

A hard-killed engine used to leave the exchange read-only until someone noticed

This only ever affected a process that died without shutting down cleanly. A normal restart releases the lease on the way out, and the replacement claims it immediately — that path always worked and is unchanged.

The dangerous case was the one nobody watches for, because every individual part of it looks correct: the engine died, the supervisor did its job, the new process started, and it correctly declined to become a second matching engine while the old lease was still held. The missing step was what happened next. There was none. The new process stayed a follower for the rest of its life.

Nothing reported it. There is no alert for "this exchange has a matching engine that is not matching", because from the outside it is a running, serving process. The symptom operators saw was orders resting and never filling, with a restart appearing to fix it at random — which it did, whenever it happened to land more than twenty seconds after the previous death.

• Fixed a matching engine that lost the lease at startup never becoming the leader again, leaving the deployment with no order matching, no position marking and no liquidation until it was restarted a second time.

Changed

Failover

• Changed a follower engine to watch for the matching-engine lease and take over when it becomes free, instead of staying read-only until restarted.
• Changed promotion to arm the order queue, the open positions and the mark sweep in that order, and to stand back down if any of them fails — so a half-armed engine can never hold the lease.