Python trade reads: preserve history pagination and expose account-wide attached inventory/account identity

オープン
#1,210 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
openapi, python
領域
api

調査の方向性

Issue で指定されている Python SDK のメソッド、TradeContext.history_orders()、today_orders(is_attached=True)、および OrderDetail.attached_orders から始めてください。これらの動作を、説明されている REST および push の契約と比較します。完了の条件は、サポート対象の API が履歴のページネーションを維持し、アカウント全体の attached-order の完全な境界を提供し、安定した読み取り専用のアカウント識別情報を公開または文書化することです。

索引モデルが issue の本文から書いたものです。

説明

bug enhancement

Summary

For safety-oriented, read-only account qualification, the Python SDK currently cannot prove three independent facts that the REST and push contracts partly expose.

Environment

  • Longbridge Python SDK: 4.4.3 and 4.5.0
  • Python: CPython 3.12
  • Operating system: Windows
  • Account environment: PAPER
  • Broker mutations performed: None

No order was submitted, replaced, or cancelled during qualification.

Observed contract gaps

1. History pagination is discarded by the Python SDK

The History Orders REST response includes a has_more pagination field. However, Python's TradeContext.history_orders() returns only List[Order].

As a result, the response-envelope boundary is unavailable to Python clients.

2. Attached orders cannot be enumerated account-wide

today_orders(is_attached=True) is an exact-order lookup mode. The official changelog states that is_attached has no effect unless an order_id is also supplied.

history_orders() has no attached-only selector.

Walking OrderDetail.attached_orders for already-observed parents therefore cannot prove that no attached-only order exists outside the observed parent set.

3. Generic trade reads lack a stable native account identifier

Generic read results such as the following do not carry a stable broker-native account identifier:

  • account balances;
  • stock positions;
  • today's orders;
  • historical orders.

PushOrderChanged.account_no exists, but it requires a future order event. It is not a harmless current-state account read.

Why this matters

A broker safety and recovery controller must distinguish between these separate claims:

  1. Current holdings are empty.
  2. No working parent order was observed.
  3. The complete account-wide order inventory is known.
  4. Every result belongs to the exact intended PAPER account.

Without these boundaries, a safety-oriented client must remain fail-closed even when the account appears flat and idle.

Requested contract

Could Longbridge provide or document any of the following?

  1. A backwards-compatible Python history result that preserves has_more, or exposes an explicit next-page or cursor boundary.
  2. A paginated, account-wide current-order inventory containing both parent and attached orders, or an attached-only enumeration with an explicit completeness boundary.
  3. A harmless, read-only account identity endpoint or field that can be correlated with generic PAPER trade reads.

If an existing supported API already provides any of these guarantees, documentation of that API would also resolve the corresponding gap.

Raw account values, credentials, and order IDs are intentionally omitted from this report.

主要言語
TypeScript
スター
61
フォーク
30
平均マージ
7時間 45分
マージ済み PR(30日)
17

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

longbridge/developers のほかの issue

longbridge/developers の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。