Skip to content

feat(BFP-5021): add DELISTING to TradeType enum + regenerate clients - #296

Merged
NidaKarim merged 2 commits into
mainfrom
nida/bfp-5021-add-delisting-trade-type
Sep 9, 2026
Merged

NidaKarim merged 2 commits into
mainfrom
nida/bfp-5021-add-delisting-trade-type

Conversation

@NidaKarim

Copy link
Copy Markdown
Contributor

What

Adds DELISTING to the TradeType enum and regenerates the ts/python/rust clients. Unblocks perpetual-ui BFP-5021 — delist-driven force-closes carry tradeType: "DELISTING" (from the backend, BFP-5019/5020, already live), and the FE should reference the SDK enum rather than a hardcoded string.

How

  • resources/common.yaml TradeType enum gains DELISTING between DELEVERAGE and UNSPECIFIED, matching the upstream pro-mono api-specs order exactly.
  • Regenerated via apigen. DELISTING lands in the correct position in every client:
    • TS ts/sdk/src/api.ts: Delisting: 'DELISTING'
    • Python .../models/trade_type.py: DELISTING = 'DELISTING'
    • Rust .../models/trade_type.rs: #[serde(rename = "DELISTING")] Delisting
  • TS typecheck (tsc -p tsconfig.esm.json --noEmit) passes.

⚠️ Version handling — please confirm before tagging a release

apigen derives one version from rust/Cargo.toml (currently on the 1.x line) and applied it to every SDK. But the TS npm package is on the 2.x line (published 2.0.0/2.1.0; perpetual-ui pins 2.1.0). Left as apigen produced it, ts/sdk/package.json would regress 2.1.0 → 1.19.0.

So in this PR:

  • rust 1.18.0 → 1.19.0 and python 1.18.0 → 1.19.0 (their own lines — unchanged behavior).
  • ts 2.1.0 → 2.2.0 — set by hand to a forward minor over the published 2.1.0 (the ts-release-* tag publishes ts/sdk/package.json's version).

The underlying rust(1.x)/python(1.x) vs ts-npm(2.x) version-line desync is pre-existing — apigen's base (rust/Cargo.toml) doesn't track the TS npm line. Not fixing that here; flagging so the maintainer picks the intended TS release version at tag time and decides whether to reconcile apigen's base.

Notes

  • Whitespace/byte-only regen noise in unrelated generated files (rust update_account_preference_request.rs, python client infra, READMEs) was reverted to keep the diff to the actual change. There is no regenerate/no-dirty CI gate (typecheck.yaml only builds/typechecks each client), so this is safe.
  • Generated api.ts shows as a "binary" diff — that's the repo's own .gitattributes (binary: set, linguist-generated: set) on generated files, not a real binary change; the only content change is the one enum line.

Follow-up

Once published, perpetual-ui #5055 bumps the dep and swaps the temporary DELISTING_TRADE_TYPE string for TradeType.Delisting.

🤖 Generated with Claude Code

Nida Ali added 2 commits September 9, 2026 10:47
Mirrors the upstream pro-mono api-specs TradeType (delist-close fills carry
this value). Ordered ORDER, LIQUIDATION, DELEVERAGE, DELISTING, UNSPECIFIED.
Regenerated via apigen. rust + python bump 1.18.0 -> 1.19.0 (their own line);
ts package bumped 2.1.0 -> 2.2.0 (its published npm line — apigen derives from
rust/Cargo.toml 1.x, which is desynced from the ts 2.x npm line; see PR notes).
Reverted whitespace/byte-only regen noise in unrelated generated files.
@NidaKarim
NidaKarim requested review from a team, alawrenc and lucasfronza as code owners September 9, 2026 14:48
@NidaKarim
NidaKarim merged commit a471b36 into main Sep 9, 2026
5 checks passed
@NidaKarim
NidaKarim deleted the nida/bfp-5021-add-delisting-trade-type branch September 9, 2026 14:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants