This is a build-in-public account of a real bug, fixed in v1.2.1 and documented in the public changelog. We're publishing the fuller technical version here because "the futures leg could stay open after closing a position" is easy to gloss over in a one-line changelog entry, and this audience deserves the actual mechanism, not just the headline.
The setup
Bitget, like several exchanges, supports two account modes for futures positions: one-way mode (a single net position per symbol) and hedge mode (separate long and short positions on the same symbol, tracked independently). FundingArb auto-detects which mode an account is in and composes orders accordingly — this is meant to be invisible to the user.
Closing a delta-neutral position means unwinding both legs: sell the spot holding, and close the futures short. The spot side is straightforward. The futures side, on a hedge-mode account, is not.
What went wrong
On most exchanges, closing a position is conceptually "place an order in the opposite direction of what you're closing." Bitget's hedge-mode close order doesn't work that way — it expects a parameter describing the position's own side (the side you're closing), not the direction of the closing order itself. Sending the intuitively-opposite value is rejected by Bitget's API with error code 22002.
spot leg: closed
futures leg: still open
The practical consequence: the spot leg closed successfully, the futures close call failed, and — because the failure wasn't caught and retried correctly at the time — the futures short stayed open on its own. That's no longer a delta-neutral position. It's a live, unhedged short, fully exposed to price risk, sitting open with nobody watching for it specifically.
How it was caught
The same release that fixed this bug (v1.2.1) also introduced a periodic runtime hedge-integrity check, running every 15 minutes by default, that compares each open position's actual exchange-side legs against the bot's tracked state and flags drift. Before that release, this comparison only ran once, at startup — meaning a leg going unexpectedly one-sided mid-session could go unnoticed until the next restart. That gap is what let this surface as a real, live problem rather than something caught immediately in testing.
The fix
The order-side parameter sent to Bitget's close-order endpoint was corrected to match what Bitget's API actually expects (the position's side, not the closing direction) instead of what other exchanges' conventions would suggest. After the fix, the change was verified live against Bitget with a real position — both legs confirmed closing correctly — and Bitget was promoted from "supported via CCXT, untested" to fully tested and live.
The lesson
"Hedge mode" is not one standardized thing across exchanges — it's an account-mode concept that each exchange's API implements with its own parameter semantics. Code that works correctly against one exchange's close-order endpoint can silently misbehave against another's, and the failure mode isn't a crash — it's a partially-executed action that looks like it might have worked. The takeaway that generalizes beyond Bitget specifically: exit and close logic needs to be tested explicitly, per exchange, with the same rigor as entry logic — not assumed to inherit correctness from it.
Why this matters if you're evaluating any automated trading tool
This is the kind of failure that a demo or a backtest will never show you, because it only exists in the gap between "the API call was sent" and "the API call did what you assumed it would do" on a specific exchange's specific account mode. It's also exactly why we publish a changelog with the bugs included, not just the feature wins — a vendor's willingness to describe its own failures in this level of detail is a better signal than a demo ever will be.