Currecy/Asset: Environment variable to Ignore enabled currency/asset check/error

[gloriousCode]

PR Description

PRs like #2159 with messages like

note: It's imperative we remove wrapper impediments for REST calls e.g. if an asset is not enabled but supported. A client should be able to call these functions outside of enabled pairs/assets trading scope for hedging and pricing. This also includes returned websocket stream data.

Make me feel FEELINGS! I think it is totally the wrong direction to take. So rather than change every single wrapper function and every single websocket implementation, I thought this opt-in check would be a better way to address the issue.

Just add environment var IGNORE_ENABLED_CHECK=true. It allows processing of non-enabled currencies and assets through wrapper and websocket functions

Fixes # (issue)

• Shazbert

• New feature (non-breaking change which adds functionality)

How has this been tested

• TestIgnoreEnabledCheckBypassPaths

Feature on:

Config:

go run . submitorder --exchange="gateio" --asset="margin" --pair="btc-usdt" --side="sell" --type="MARKET" --amount="1"
2026/02/13 09:29:36 rpc error: code = Unknown desc = GateIO unsuccessful HTTP status code: 403 raw response: {"message":"Request API key does not have spot write permission","label":"FORBIDDEN"}
, authenticated request failed

go run . getticker --exchange="gateio" --asset="margin" --pair="eth-usdt"
{
 "pair": {
  "delimiter": "-",
  "base": "eth",
  "quote": "usdt"
 },
 "last_updated": 1770935492,
 "last": 1928.25,
 "high": 2001.62,
 "low": 1896.71,
 "bid": 1928.25,
 "ask": 1928.26,
 "volume": 105785.5351
}%   

Feature off:

go run . submitorder --exchange="gateio" --asset="margin" --pair="btc-usdt" --side="sell" --type="MARKET" --amount="1"
2026/02/13 09:41:23 rpc error: code = Unknown desc = margin asset type not enabled

go run . getticker --exchange="gateio" --asset="margin" --pair="eth-usdt"
2026/02/13 09:35:56 rpc error: code = Unknown desc = margin asset type not enabled
exit status 1

[gemini-code-assist]

Code Review

This pull request introduces a feature to bypass the enabled currency/asset checks via the IGNORE_ENABLED_CHECK environment variable. The implementation correctly applies this bypass logic across several functions in the currency package. My review focuses on a performance improvement opportunity and a bug in the accompanying test. Specifically, the function for checking the environment variable is inefficient and should be optimized to read the value only once. Additionally, the new test case has a case-sensitivity issue with the environment variable key that will cause it to fail on some operating systems.

[thrasher-]

@codex please review

[Copilot]

Pull request overview

Adds an opt-in environment-variable bypass to allow wrapper/WebSocket paths to operate on supported-but-not-enabled assets/pairs by ignoring “enabled” checks at the currency/asset layer.

Changes:

• Introduces IGNORE_ENABLED_CHECK env var handling in currency.PairsManager to bypass asset/pair enabled gating.
• Adjusts enabled/available checks (GetAssetTypes, GetPairs, EnsureOnePairEnabled, IsPairAvailable, IsPairEnabled, IsAssetEnabled) to honor the bypass.
• Adds a unit test covering the bypass behavior across several call paths.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
currency/manager.go	Adds env-var driven bypass and updates multiple “enabled”/availability decision points accordingly.
currency/manager_test.go	Adds a test validating behavior with bypass off vs on.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8849809e52

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[shazbert]

So there is two competing philosophies here.

PR #2159 (mine) — Remove the enabled-pairs filter from UpdateTickers wrapper functions entirely. Match against available pairs instead. The wrapper layer becomes agnostic — it fetches and stores everything the exchange supports, and filtering is left to higher layers (engine, strategy, CLI).

This — Keep the existing enabled-pairs checks in place but add an IGNORE_ENABLED_CHECK env var that globally bypasses them when set to true. The wrapper layer keeps its filter but callers can opt out.

From my perspective wrapper/exchange layer's job is to translate exchange API responses into internal types. Policy decisions about which pairs to surface belong in the application layer (engine, gRPC handlers, strategies). Embedding an "enabled" filter inside a REST-response-processing loop conflates data acquisition with business logic. #2159 pushes that boundary outward.

Main isssues with this PR:

• A package-level init() + global var checked inside hot paths (IsPairEnabled, GetAssetTypes, etc.) is a hidden side-channel. It makes functions behave differently depending on process-level state that isn't visible in their signatures or documentation.
• It circumvents IsPairEnabled to return true for pairs that are only available — this subtly violates the function's contract and could confuse callers who rely on IsPairEnabled meaning "the user explicitly enabled this pair".

@thrasher- @samuael

[gloriousCode]

I agree this shouldn't be a PR. It was mostly to help you achieve your goals of not having filtering without requiring massive amounts of code changes and not needing to call "enable all pairs" every time a new pair is added