Core v6.8.4

Release Date: October 1, 2026 Tags: UPDATES, ADMIN, TRADING

Overview

Updating from the admin panel now finishes the job. Until this release the panel's update buttons only downloaded a release and unpacked it over the site. Nothing took effect until someone ran pnpm updator on the server. Now Update All, core's Install v… and an add-on's own update button download every pending release in order and then apply them: dependencies, database, rebuild and restart. The site shows its maintenance page for 10 to 20 minutes and comes back on the new versions. Update All now includes core.

The VENDOR_MANAGED_UPDATES setting, which stopped the panel downloading, is removed.

Spot orders the exchange accepted and the platform has not recorded yet are no longer shown to the customer as a success. An order whose recording is refused outright now goes straight to an operator, marked Needs Review, instead of being retried for half an hour. An order the platform could not read back from the exchange is no longer lost.

Update Instructions

pnpm updator

Run it on the server this once. The panel that downloads 6.8.4 is the 6.8.3 one, and that panel only downloads. From 6.8.4 onwards updates from the panel apply themselves. There is no schema change, no seeder change and no new .env key.

Published with this release: Staking v6.2.9, which carries the faster admin pool pages that Staking v6.2.8 described but did not contain. It needs Core 6.8.3 or later.

Upgrade Notes

Getting to 6.8.4

• Downloaded from the panel of 6.8.3 or older, 6.8.4 is only unpacked. Run pnpm updator on the server afterwards, or update from the server with pnpm update-all, which downloads and applies in one go.
• If your .env has VENDOR_MANAGED_UPDATES="true", a 6.8.2 or 6.8.3 panel refuses to download at all. Update from the server with pnpm update-all. From 6.8.4 the line does nothing; delete it.

What an update from the panel does from now on

• It takes the site down. Pick a quiet time: the maintenance page is up for 10 to 20 minutes, longer on a slow server.
• Before stopping, it waits up to two minutes (GRACEFUL_STOP_TIMEOUT_MS) while any withdrawal is pending or processing. A withdrawal waiting for your approval counts, so with one in the queue the stop always waits the full two minutes.
• It restarts the backend. If you unlock the ecosystem wallets with a passphrase in the admin panel rather than keeping ENCRYPTION_KEY_PASSPHRASE in .env, enter the passphrase again afterwards (Admin → Ecosystem), or native withdrawals fail until you do.
• Each run is recorded in updates/finalize-status.json and its full output is appended to updates/finalize.log, both under the project root. While the frontend is rebuilt, the previous build is kept as frontend/.next.before-update and deleted once the build succeeds.
• If the stop, seed or build step fails, the site keeps running (a failed build puts the previous frontend back) and the update dialog offers Try Again.
• If the dependency, database or start step fails, the site stays on its maintenance page. Read updates/finalize.log on the server, fix the cause and run pnpm updator.
• The buttons need the same create.license permission as before.

Spot orders that need a person

• Search the log for its booking was REFUSED. That order is on your exchange account and the platform will not record it on its own. It is marked Needs Review under Admin → Order Management → Spot Orders, with the reason, and the line says where its details are kept.
• Orders given up by the spot order job, and platform fees it could not collect, carry the same marker.

Added

Updates that apply themselves

• Added the apply step to every update button in the panel. After the downloads it runs the same chain as pnpm updator: a graceful stop, then dependencies, database, seed data, frontend build and start. It runs whenever anything was downloaded, even if another product failed or the run was stopped part-way.
• Added the step list to the update dialog. While the backend is down, the maintenance page answers with the current step only, so the dialog keeps following it. The page reloads itself once the site is back.
• Added Try Again to the dialog for an apply step that failed with the site still up. A second Update All would not retry it: the releases are already downloaded, so it finds nothing to install.
• Only one apply run can happen at a time. A second request, from another tab or another admin, is refused with "The updates are already being applied", and the dialog follows the run in progress.

Needs Review on spot orders

• Added a Needs Review badge to the spot order list and a Needs Review section on the order itself, listing what the platform could not do for that order, in the words it logged.

Changed

Update All includes core

• Changed Update All on Add-ons & Integrations to update core first, then every licensed add-on, blockchain and exchange provider. Its dialog is now called "Update everything". If core has an update that does not finish, the add-ons are not attempted, because they are built for the new core.
• Changed Install v… on System Updates to install every pending core version in one go. It used to install one version per click.
• Changed Install v… and Update Now on an add-on's own page to apply the update as well as download it.

Spot orders accepted but not yet recorded

An order is sent to the exchange first and recorded second. When the recording cannot be done at once, the order already exists on the exchange.

• Changed what the customer is told. When the platform will finish recording it: "Your order was placed on the exchange and is still being recorded. Do not place it again. Reference: …". When a person has to: "Your order was placed on the exchange but could not be recorded automatically. Support has been alerted — do not place it again. Reference: …". The reference is the exchange's order id.
• Changed the website to show both as a warning instead of a green success. The pro trading screen no longer adds such an order to the customer's open orders as if it were placed; it reloads their orders and balances instead. Mobile apps already installed still report the order as placed.
• Changed an order whose recording is refused for a reason no retry can cure (the funds were used by another order in the meantime, there is no usable fill price, a wallet is disabled or missing) to go to review at once. Before, the spot order job retried it every minute for about half an hour and then gave up. See Upgrade Notes for the log line.

Fixed

An order the exchange accepted and the platform could not read back

Core 6.8.3 listed this as not fixed. After the exchange accepted an order, the platform reads it back to see what filled. When that read failed, the customer got an error and nothing was recorded, while the order stood or filled on your exchange account.

• Fixed the order being lost. It is now saved as an open order with nothing filled, and the spot order job asks the exchange about it every minute and records whatever the exchange reports: filled, partly filled, still open or cancelled.
• If the exchange answers that it has no such order three times, and the order is at least ten minutes old, it is recorded as cancelled with nothing filled.
• An order placed on a different exchange from the one the platform trades on now cannot be read from here, and goes to review.

Removed

• Removed VENDOR_MANAGED_UPDATES. On 6.8.2 and 6.8.3 it made the panel refuse every download with "Updates are applied by your provider on this installation". Downloads are checked against the publisher's checksum before anything is unpacked, which covers the truncated download the setting was added for.