Hummingbot Connector v6.0.8

Release Date: August 12, 2026 Tags: CRITICAL FIXES, ORDERS, MARKET MAKING, CONNECTOR, RATE-LIMITS, BOT CONSOLE, INTERFACE

Overview

A stuck-order release, and it is the most damaging fault this connector has had. When the exchange refused a cancel — a rate limit, a bad gateway, a dropped connection — the connector gave up on it silently. Hummingbot stopped tracking the order; the exchange did not. The order stayed resting on the book with your funds committed to it, invisible to status and to the strategy that had already written it off.

Everything follows from that. The locked funds refuse the next order for insufficient balance on an account that has money, and the abandoned quote keeps tripping the venue's self-match guard, so the opposite side is refused too. One such order blocked 399 consecutive quotes over nine minutes on a live install. Hummingbot reports all of it as Check API key and network connection, which is why it read as a connectivity problem.

Read Upgrade Notes before you update — an order abandoned by an earlier version is open on your exchange right now, and updating does not retract it. This release also requires a connector reinstall. Alongside it, the bot console no longer fails outright on a market with a one-sided book, and it stops going blank when you open it in a second tab.

Requires Core v6.6.4.

Update Instructions

This release requires a connector reinstall. The order fix is Python that runs inside your Hummingbot checkout, so pnpm updator alone changes nothing for a running bot. Update the platform first:

pnpm updator

Then reinstall into every checkout you run a bot from, from your platform root (public_html), in the Hummingbot conda environment:

python hummingbot/install_connectors.py /path/to/hummingbot

Restart the backend and your bots afterwards. No database migration.

Upgrade Notes

Check for orders left behind by earlier versions

A cancel dropped by an older connector is still open on the exchange right now, and updating does not retract it — nothing on the platform side knows it was ever meant to be cancelled. Open your exchange order book and cancel anything resting that your bot is not tracking, particularly on any account that has been reporting insufficient balance while holding funds.

The tell is a single unchanging price: one abandoned order rejecting hundreds of quotes always names the same price in the refusal, while a genuine pricing problem moves.

• Fixed a refused cancel being abandoned, leaving the order live on the exchange with the account's funds committed to it.
• Cancel any untracked resting orders before restarting your bots, or they will keep refusing quotes on both sides.

Fixed

A refused cancel was given up on, and the order stayed live

Cancelling was a single attempt. Any refusal ended it and the strategy moved on — but a cancel is not a request that can be dropped, because until it lands the exchange is still holding the order and the funds behind it. The two failures that mattered were a rate limit and a gateway error, both of which are temporary and both of which the connector treated as final.

A cancel is now retried for up to 51 seconds across seven attempts, backing off between them, and a cancel that races a fill or lands on a later attempt is correctly recognised as a cancel that succeeded rather than reported as a failure.

• Fixed a cancel refused by a rate limit or a server error being abandoned after one attempt, leaving the order resting on the exchange while Hummingbot stopped tracking it.
• Added a plainly worded error when a cancel genuinely cannot be delivered, naming the order and saying that it is still live and still holding funds so it can be cleared by hand. Hummingbot's own message for this says only that the cancel failed, which does not tell you that anything is still open.
• Changed order placement to retry only a rate-limit refusal, which is declined before the exchange has looked at the order. A placement that fails with a server error is not retried, because the order may already exist and sending it again would either duplicate it or report a failure for an order that is live. Placement gives up quickly by design — the price is stale within a tick and the strategy re-quotes on its next cycle.
• Fixed the same dropped-cancel behaviour in the perpetual connector, where it left margin committed to a position leg the bot believed it had closed.

Rate-limit refusals reached bots far below their budget

The refusals that caused all of the above were not the connector's fault, and the connector could not have paced around them: it throttles itself against the per-key trading budget, and what was refusing it was the platform's separate per-address limit, whose allowance had stopped renewing. That is fixed in Core v6.6.4, and both halves are needed — the platform stops refusing legitimate traffic, and the connector survives the refusals that remain.

• Changed the connector to recognise a rate-limit refusal by the exchange's own error code as well as by the response status, so a proxy that rewrites the status no longer hides it.

The bot console showed an error page on a one-sided book

A market maker's distance from the touch is measured against the mid price, and a mid needs a bid and an ask. When the console met a market where your bot had a quote resting but the book could not produce a mid, it stopped rendering — and because the console is a full-screen terminal that carries no page furniture of its own, there was nothing underneath to fall back to. The entire screen became an error page, Emergency Stop included, so the fastest way to halt a bot was on the far side of the failure; stopping one meant going to API Keys and disabling its key instead.

The condition that triggered it is ordinary and is not a fault in your setup: a thin market whose asks have all been taken, a book that could not be read, a pair whose engine has stopped publishing one. It struck hardest on exactly the markets the console has the most to say about. The bitter part is that this is a state the console already knows how to explain — No liquidity on this market and The book has no asks are verdicts it has always been able to write, and they were unreachable because the page died before it could say any of it. Anyone hosting bots for others met the same failure on the instance panel in the admin section, which draws the same terminal.

• Fixed the console failing outright for any account with a quote resting on a market that has no mid price. A side that cannot be measured now reads —, carrying the same explanation the spread picture beside it already gave for the same condition, and the page renders the verdict it was written to render.

A second console tab froze on its first paint, and closing it blanked the first

The platform recorded one live connection per operator per screen, so opening the console a second time replaced the first connection in its records. The older tab was never told: it stayed open, went on saying it was connected, and stopped receiving anything. The newer one had the opposite problem where the console's own updates were concerned — those were addressed to a single connection per account, so a second tab sat on its first paint indefinitely while the first tab got everything.

Closing either one then tore down the account's console state entirely, so the tab that was left blanked as well. And the terminal's has anything changed since the last update memory was kept per account rather than per view, so two tabs narrowed to different markets overwrote each other's and each was told nothing had moved.

• Fixed a second console or terminal tab replacing the first, leaving it open, silent and still reporting itself connected.
• Fixed closing one console tab blanking the others that account had open.
• Fixed two tabs narrowed to different markets cancelling each other's updates, which left both showing stale figures.
• Fixed a private stream being matched against one connection's identity while being checked against another connection's subscriptions, so an agent that was still attached could be reported offline.

Rate-limited cancels are answered rather than counted twice

The platform's per-address rate limit had a window that could not close, which is what produced the refusals described above. It is fixed in Core v6.6.4, and the figure the platform reports back for requests remaining is now measured after the request has been counted — so two requests arriving together no longer both report the same allowance and overstate what is left.

• Changed the remaining-allowance figure returned to the connector to be accurate under concurrency.

The console threw away its own page and rebuilt it on every load

The terminal is rendered on the server before it reaches you, so it arrives drawn rather than assembling itself in front of you. Its status-bar clock was rendered there as well — from the server's wall time, in the server's own timezone — and your browser then disagreed with what it had been handed. A browser does not patch a disagreement of that kind: it discards the server's entire page and builds a fresh one. So the terminal was constructed twice on every single load, and on a platform whose server keeps UTC the time in that first copy was not a second stale but several hours wrong.

• Fixed the clock being drawn on the server. It starts once the page is running in your browser, so the server's copy is no longer contradicted and no longer thrown away — the terminal now appears once, and the first thing you see is the time where you are.

The troubleshooting guide now covers the connectivity warning

The connector kit's own guide gained an entry for the symptom operators actually see — Check API key and network connection on an install where both are fine — explaining the chain from a dropped cancel to insufficient balance and self-match refusals, how to recognise it from the unchanging price in the refusal, and what to check on the server if rate-limit refusals continue.

• Added a troubleshooting entry for the misleading connectivity warning and the stuck-order chain behind it.