Is session.idle a causal accounting/event-completeness boundary in the native/headless protocol?
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 10/100
- issue の種類
- ドキュメント
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
調査の方向性
Start from the SDK documentation that defines session.idle semantics and the generated event surface (assistant.usage, session.usage_info, session.usage_checkpoint, session.compaction_start/complete, assistant.turn_end, assistant.idle) in github/copilot-sdk; trace where those events are produced and where session.idle is enqueued for CLI 1.0.92-3 (and 1.0.91 if semantics differ). Read issue #4743 only for contrast — it covers ACP prompt completion, which this question explicitly excludes. Done means a versioned YES / NO / UNSPECIFIED statement about causal emission ordering, plus any stronger supported RPC, event, watermark or barrier if the answer is NO or UNSPECIFIED.
索引モデルが issue の本文から書いたものです。
説明
We integrate GitHub Copilot CLI through the public Copilot SDK and need a deterministic session/accounting completion boundary. This is a protocol-contract question, not a request for a timing workaround.
For Copilot CLI 1.0.92-3 (bundled by github/copilot-sdk v1.0.17-preview.3, commit ef04633), the current public documentation describes session.idle as the point where the agent has finished all processing, is ready for the next message, and the turn is fully complete.
The generated event surface also includes events such as:
- assistant.usage
- session.usage_info
- session.usage_checkpoint
- session.compaction_start
- session.compaction_complete
- assistant.turn_end
- assistant.idle
- session.idle
The remaining question is specifically about causal event emission ordering.
For CLI 1.0.92-3, and if the semantics differ please also note CLI 1.0.91:
When a client observes session.idle on the native/headless protocol stream, is it guaranteed that every session event/notification attributable to work completed before that idle point has already been generated and enqueued onto the ordered client transport?
In particular, after the observed session.idle, can any event attributable to the preceding work still legitimately be generated/emitted that changes usage/accounting or other completion-relevant state, including assistant.usage, session.usage_info, session.usage_checkpoint, or compaction-related accounting?
A concise versioned answer in one of these forms is sufficient:
YES, guaranteed for version X — before session.idle is emitted, all producers relevant to the preceding work are finalized and all corresponding events are queued into the ordered transport domain; no accounting/completion-relevant event attributable to that preceding work can legitimately be emitted afterward.
NO — session.idle guarantees that agent processing has stopped / the turn is complete in the documented sense, but it is not an event/accounting emission fence.
UNSPECIFIED / unsupported contract — the implementation may currently exhibit an ordering, but SDK clients must not depend on that ordering.
If the answer is NO or UNSPECIFIED, is there another currently supported native/headless RPC, event, watermark, or barrier that provides the stronger property?
We are specifically not treating sleeps, quiet periods, repeated polling, local queue-empty observations, or ordinary JSON-RPC response ordering as substitutes for such a guarantee.
The distinction matters because FIFO transport can prove ordering for frames that have already entered the transport, but cannot by itself prove that an upstream/background producer will not subsequently create another event attributable to the preceding work.
A version-specific semantic statement is sufficient; no proprietary backend implementation details are required.
This question is related to, but intentionally narrower than, github/copilot-cli#4743: that issue concerns ACP prompt completion. Here the question is specifically about the existing native/headless session.idle contract used by the public Copilot SDK.
- 主要言語
- Java
- スター
- 10.7k
- フォーク
- 1.5k
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
github/copilot-sdk のほかの issue
-
Rust: ElicitationRequest drops the tool call id from elicitation.requested再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
github/copilot-sdk#2900 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 84/100
github/copilot-sdk#2876 · コメント 1 件 · リアクション 1 件 ·
-
Python ModelLimits drops max_output_tokens from model metadata再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
github/copilot-sdk#2798 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
github/copilot-sdk#2759 ·
-
docs/AGENTS.md is repo authoring guidance, but everything in docs/ gets published再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープンdocumentation
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
github/copilot-sdk#2758 ·
github/copilot-sdk の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
ls1intum/thesis-management#1473 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
LunaDeerMC/Dominion#301 · コメント 1 件 ·
-
[FEATURE] Expose external refresh, node-level translog and warmer stats対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンuntriaged
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
opensearch-project/opensearch-prometheus-exporter#680 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
メンテナーはふだん 2 日以内に返信