Forex & Multi-Asset Trading v6.0.5

Release Date: August 23, 2026 Tags: LOGGING, DIAGNOSTICS, QUOTES, BUG-FIXES

Overview

A quote feed that could not connect wrote a 7 GB error log on a live install, and buried every other error in the file with it. The cause was not the feed being down — that part worked as designed. It was that the same sentence was written to disk about four times a minute, for as long as the process ran.

The quote stream retries forever on purpose: a provider that is having a bad minute must recover without anybody logging in. So it re-opens its circuit every sixty seconds and reports the refusal. That is exactly right when the refusal is temporary and exactly wrong when it is permanent — an API key on a plan that carries no websocket entitlement is refused identically every time, and the platform announced it again every sixty seconds, from two places at once.

Repeated refusals are now folded into one line carrying a count. The status the operator's diagnostics read is untouched — suppressing a log line must never suppress the state behind it, and the forex status panel still reports the live reason the feed is down. Requires Core v6.7.0.

Update Instructions

pnpm updator

Restart the backend afterwards. There is no database change and no migration.

Upgrade Notes

Check the size of your backend error log before you restart

If your quote provider has been refusing the websocket connection, the log this release stops writing is already on disk and this update does not remove it. Check backend/logs and rotate or delete anything oversized before restarting, or the next boot inherits a file large enough to matter to the disk.

The reason your feed is down is still worth reading once. The commonest by far is an API key whose plan does not include streaming quotes, which the provider refuses at the handshake — the platform reports it, and it looks exactly like an outage until you know.

Fixed

The quote stream reported the same failure four times a minute, forever

The reconnecting quote stream keeps its circuit half-open by design: it backs off to a maximum of sixty seconds and keeps trying, so a provider that recovers on its own brings the feed back with no intervention. Every one of those attempts that was refused wrote an error line, and the tick engine wrote a second one from its own status callback.

For a temporary outage that is a handful of lines. For a permanent refusal — the provider rejecting the key at the handshake, which never changes on retry — it is a line every fifteen seconds for the life of the process. One live install reached 7 GB, at which point the log was no longer usable for anything else: every unrelated error was somewhere inside it.

• Fixed the circuit-open error repeating. A refusal that differs from the last one is still reported immediately; an identical one is held back and folded into a single line every thirtieth occurrence, carrying how many times it has now repeated.
• Fixed the same repetition in the tick engine's stream-status log, which was the second half of the volume. Its dedupe is on the reason, not on the status changing — the stream genuinely transitions to reconnecting and back to failed on every backoff, so a transition guard would have suppressed nothing.
• Changed nothing about the recorded state. The stream status and its current reason are still updated on every attempt, so the diagnostics panel and the status endpoint report the feed as down at the moment it goes down, not on the thirtieth try.