Repository navigation
feat(trade): add attached-order depth levels - #607
Merged
Merged
Conversation
Documented in longbridge/developers#1189. - SubmitAttachedParams / ReplaceAttachedParams gain profit_taker_depth_level / stop_loss_depth_level (int32): the bid/ask depth level for the take-profit / stop-loss limit order submitted price, valid when activate_order_type is LIT. - AttachedOrderDetail gains limit_depth_level, read from attached_orders[].limit_depth_level; 0, null or a missing field read as unset. - Mirrored across C (fields appended at the end of the structs; header regenerated), C++, Java, Node.js (index.d.ts regenerated) and Python (+ openapi.pyi).
Accept an integer or a numeric string; null, 0 or an invalid value read as unset instead of failing the whole order response. CHANGELOG: note that the C option structs grow.
hogan-yuan
added a commit
to longbridge/openapi-go
that referenced
this pull request
Oct 15, 2026
Also link longbridge/openapi#607 in the CHANGELOG entry.
hogan-yuan
added a commit
to longbridge/openapi-go
that referenced
this pull request
Oct 15, 2026
Ports longbridge/openapi#607, which follows [longbridge/developers#1189](longbridge/developers#1189). ## Changes - `SubmitAttachedParams` and `ReplaceAttachedParams` gain `ProfitTakerDepthLevel` and `StopLossDepthLevel` (`int32`, not sent when `0`). Each is the bid/ask depth level used for the take-profit or stop-loss limit order's submitted price, and only applies when `ActivateOrderType` is `LIT`. - `AttachedOrderDetail` gains `LimitDepthLevel` (`int32`, `0` when not set), read from `attached_orders[].limit_depth_level` in `TodayOrders`, `HistoryOrders` and `OrderDetail`. A JSON `null` reads as `0`. ## Verification - `go build ./...`, `go vet ./trade/...` and `go test ./trade/...` pass. - `trade/attached_depth_level_test.go` goes through the real `util.Copy` and `encoding/json` path. It checks: - the depth levels reach `attached_params` on submit and replace, and are omitted when zero - `limit_depth_level` values of `3`, `0` and `null` on a response ## Note The docs examples show `attached_type_display`, `trigger_status` and `tag` in `attached_orders` as integers. This SDK, like the Rust core, reads them as strings, so one of the two is wrong. See the note on longbridge/openapi#607. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
This was referenced Oct 16, 2026
Merged
hogan-yuan
added a commit
to longbridge/openapi-go
that referenced
this pull request
Oct 16, 2026
Cut **v0.29.2** — closes out the `[Unreleased]` CHANGELOG section as `[v0.29.2] - 2026-10-16`. ## Included since v0.29.1 - **Added — attached-order depth levels** (#132): `SubmitAttachedParams` / `ReplaceAttachedParams` gain `ProfitTakerDepthLevel` / `StopLossDepthLevel` (`int32`, not sent when `0`, valid when `ActivateOrderType` is `LIT`), and `AttachedOrderDetail` gains `LimitDepthLevel`. Ports longbridge/openapi#607 (longbridge/developers#1189). Only `CHANGELOG.md` changes. The `v0.29.2` tag is created after merge. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
hogan-yuan
added a commit
that referenced
this pull request
Oct 16, 2026
Release **v5.2.2**. Bumps workspace `5.2.1` → `5.2.2`. ### New since v5.2.1 - **Added:** attached (take-profit / stop-loss) orders gain bid/ask depth levels (longbridge/developers#1189). `SubmitAttachedParams` / `ReplaceAttachedParams` gain `profit_taker_depth_level` / `stop_loss_depth_level` (int32, valid when `activate_order_type` is `LIT`), and `AttachedOrderDetail` gains `limit_depth_level`. Across Rust, C, C++, Java, Node.js and Python (the Go SDK ships separately, openapi-go#132) (#607) ### Release pipeline (no SDK changes) - Java: bump `central-publishing-maven-plugin` to 0.12.0 so Maven Central accepts bundles built with Maven 3.10 (#606) - Node.js: skip npm publish when the version is already published, so re-running the Release workflow no longer fails with E403 (#608) - Lower the Linux gnu glibc baseline for the Node.js & Python SDKs (#609) Only `Cargo.toml` (workspace version + internal dep reqs) and `CHANGELOG.md` change. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follows longbridge/developers#1189, which documents depth levels for attached (take-profit / stop-loss) orders.
Changes
attached_params.profit_taker_depth_level/stop_loss_depth_level(int32, valid whenactivate_order_typeisLIT)SubmitAttachedParams/ReplaceAttachedParamsgain both fields; omitted from the request when unsettoday_orders/history_orders/order_detailattached_orders[].limit_depth_level(int32)AttachedOrderDetail.limit_depth_level;0,nullor a missing field read as unset, matchingOrder.limit_depth_levelAll six layers, per the checklist in
CLAUDE.md:profit_taker_depth_level(i32)/stop_loss_depth_level(i32)builders andAttachedOrderDetail.limit_depth_level: Option<i32>. A smallint32_opt_null_or_0_is_nonedeserializer keeps the new response field tolerant ofnull.const int32_t *fields appended at the end ofCSubmitAttachedParams,CReplaceAttachedParamsandCAttachedOrderDetail(header regenerated by cbindgen).std::optional<int32_t>on the three types plus both conversion directions.setProfitTakerDepthLevel(Integer)/setStopLossDepthLevel(Integer)on both params classes andAttachedOrderDetail.getLimitDepthLevel(), with the JNI layer to match.profitTakerDepthLevel?/stopLossDepthLevel?andget limitDepthLevel(): number | null.index.d.tswas regenerated;index.jsis unchanged.profit_taker_depth_level/stop_loss_depth_levelkeyword arguments on both params classes andAttachedOrderDetail.limit_depth_level, plus theopenapi.pyistub.Go SDK counterpart: longbridge/openapi-go#132.
Verification
cargo test -p longbridge --lib: 73 passed. New tests cover the request serialization of both params types (omitted when unset), andlimit_depth_levelfor0,3,nulland a missing field.cargo clippy --all --all-features: no new warnings.cargo +nightly fmt --allwas applied.cargo build -p longbridge-c,clang++ -fsyntax-onlyoncpp/src/trade_context.cpp,cargo build -p longbridge-java+mvn compile,cargo check -p longbridge-python, andnpm run build:debug.Note: possible docs/SDK mismatch, out of scope here
The docs example in #1189 (and the existing docs) shows
attached_type_display,trigger_statusandtaginattached_ordersas integers, e.g."attached_type_display": 2. Both the Rust and Go SDKs parse these as strings (STOP_LOSS,NOT_USED,Normal), and the docs example fails to deserialize as written. One of them is wrong. It should be checked against a real response that has attached orders.🤖 Generated with Claude Code