You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At that exact moment the connector was just created with trading_pairs=[], and the py-base _execute_set_position_mode logs "No trading pairs configured, cannot set position mode." and returns — so this call has never reached any exchange. The intended mode is not persisted anywhere (_perpetual_trading.position_mode is only updated on success), so it cannot be retried later.
Consequence
Perpetual accounts run in whatever mode the exchange already had (account default or last manual setting), while the API's code reads as if HEDGE is the guaranteed default. Executors then compute position_action under one assumption and the exchange enforces another, surfacing as order-time errors far from the cause.
#209 makes the endpoint honest (registers a provided pair, 400s instead of silently succeeding), but deliberately leaves the init-time call untouched: making it suddenly effective would flip long-running accounts from their current exchange mode to HEDGE on the next API restart — a live-behavior change that deserves its own decision, not a rider on a bugfix.
Suggested direction
Record the intended mode at init (e.g. pending_position_mode) instead of firing a call that cannot work, and apply it on the FIRST pair registration for the connector (sync_pair_derived_state from (fix) sync pair-derived connector state (throttler limits, trading rules) on dynamic pair registration #209 is the natural hook). The base _execute_set_position_mode already fetches the exchange mode first and no-ops when it matches, so re-firing is idempotent.
Decide explicitly whether a silent HEDGE default is even desirable, or whether mode should only ever be set through the (now honest) endpoint.
Related: hummingbot-api-client needs a trading_pair field on set_position_mode to use #209's registration path directly; until then callers must set leverage first (which registers the pair) or pre-add the market.
Summary
Follow-up to #207/#208 (dynamic-pair state family), split out of PR #209 deliberately.
UnifiedConnectorService._create_and_initialize_trading_connector()sets a HEDGE default on perpetual connectors at init:At that exact moment the connector was just created with
trading_pairs=[], and the py-base_execute_set_position_modelogs "No trading pairs configured, cannot set position mode." and returns — so this call has never reached any exchange. The intended mode is not persisted anywhere (_perpetual_trading.position_modeis only updated on success), so it cannot be retried later.Consequence
Perpetual accounts run in whatever mode the exchange already had (account default or last manual setting), while the API's code reads as if HEDGE is the guaranteed default. Executors then compute
position_actionunder one assumption and the exchange enforces another, surfacing as order-time errors far from the cause.Why PR #209 does not fix this
#209 makes the endpoint honest (registers a provided pair, 400s instead of silently succeeding), but deliberately leaves the init-time call untouched: making it suddenly effective would flip long-running accounts from their current exchange mode to HEDGE on the next API restart — a live-behavior change that deserves its own decision, not a rider on a bugfix.
Suggested direction
pending_position_mode) instead of firing a call that cannot work, and apply it on the FIRST pair registration for the connector (sync_pair_derived_statefrom (fix) sync pair-derived connector state (throttler limits, trading rules) on dynamic pair registration #209 is the natural hook). The base_execute_set_position_modealready fetches the exchange mode first and no-ops when it matches, so re-firing is idempotent.Related:
hummingbot-api-clientneeds atrading_pairfield onset_position_modeto use #209's registration path directly; until then callers must set leverage first (which registers the pair) or pre-add the market.