5.1 KiB
5.1 KiB
| title | state | created_at | updated_at | assignee | readiness | risk_flags | queued_by | queued_at | |||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Panel Quit 時の断続的な遅延を調査して解消する | done | 2026-06-13T10:04:55Z | 2026-06-13T11:41:26Z | null | spike_needed |
|
workspace-panel | 2026-06-13T10:53:17Z |
Background
Panel から Quit するときに、終了まで遅延が発生することがある。ユーザー観測の断続的な UX 劣化として扱い、原因を調査したうえで修正する。
関連しそうな既存記録として、Panel の非同期遷移/フリーズ回避に関する 00001KTFMMZP0 は closed。今回の主対象は Quit 操作の遅延であり、同一目的の未完了 Ticket は確認できなかった。
Request snapshot
- 依頼: 「PanelからQuitするときに遅延が発生することがある。調査して修正チケット切って」
- handoff workspace:
yoi - workspace_orchestrator_pod:
yoi-orchestrator
Requirements
yoi panel/ workspace Panel の Quit 操作で、ユーザー入力後に不必要な待ちが発生する原因を特定する。- Quit は、通常の端末復旧や安全な最小限の cleanup を除き、進行中の reload / notice dispatch / snapshot 読み込み / Pod 状態観測などの完了待ちでブロックされないこと。
- 断続的な遅延であっても、原因が再発しにくい形で修正する。単に poll interval を短くするだけの対症療法にしない。
- 既存の Panel 役割、Ticket 操作、Companion/Orchestrator composer target、row selection semantics を壊さない。
Acceptance criteria
- Quit 入力(現状の
Ctrl+C/Ctrl+D経路を含む)が、Panel の background reload や queue-attention notice などの非本質的処理待ちで目に見えて遅延しない。 - 遅延原因と修正方針が implementation report に説明されている。
- 可能な範囲で unit test または小さな regression test が追加され、少なくとも Quit 経路が pending background work によってブロックされないことを検証する。
- 自動化が難しい場合は、manual validation 手順と観測結果を implementation report に残す。
Binding decisions / invariants
- Quit はユーザーの明示的な終了意思であり、Panel の観測/reload/通知送信の完了を待つために遅延してはならない。
- ただし端末状態復旧、描画 backend の正常終了、Rust drop による安全な abort など、最小限の終了処理は維持する。
- Quit 改善のために Ticket lifecycle authority、Pod authority boundary、Panel row/action semantics を変更しない。
resources/promptsや durable Ticket schema の変更を伴う必要は、現時点では想定しない。必要になった場合は escalation する。
Implementation latitude
- まず
crates/tui/src/multi_pod.rsの Panel event loop /PendingReload/ Quit handling 周辺を調査する。 - 必要に応じて quit 受付前後の await、background task abort/drop、terminal event polling、queue-attention notice dispatch、snapshot load の相互作用を確認する。
- 修正手段は実装者に委ねるが、終了時に不要な await を避ける、Quit 前に cancellable background work を abort する、または event loop の優先度を調整するなど、設計上説明可能な変更にする。
- 再現が難しい場合は、遅延し得るコードパスを単体で再現できる test seam を作ることを優先してよい。
Readiness
- readiness: spike_needed
- 理由: 現象は明確だが断続的であり、現時点では再現条件・遅延箇所・影響する async path が未特定。先に短い調査/計測または code-path analysis が必要。
- risk_flags: [tui-panel, shutdown-latency, async-cancellation]
Open questions
- 遅延の典型時間、発生頻度、再現しやすい Panel 状態(reload 中、Orchestrator notice 中、Pod 多数、dirty workspace 等)は未提供。実装者は必要なら調査中に記録する。
Escalation conditions
- 修正に Panel の public UX、Ticket lifecycle semantics、Pod shutdown semantics、authority boundary の変更が必要になりそうな場合は Orchestrator/maintainer に戻す。
- 端末 cleanup や Pod process lifecycle を犠牲にしないと遅延を解消できない場合は、方針判断を求める。
- 遅延の原因が Panel 外(OS 端末、shell、external command、specific provider/network)にある場合は、証拠と切り分け結果を残して routing し直す。
Validation
- 変更内容に応じて
cargo test -p yoi-tuiまたは該当 crate の focused test を実行する。 - 必要に応じて
cargo check/git diff --checkを実行する。 - 可能なら
yoi panelを実際に起動し、background reload があり得る状態でも Quit が速やかに戻ることを手動確認する。
Related work
00001KTFMMZP0: Panel の非同期遷移/フリーズ回避に関する closed Ticket。今回の修正で既存判断と矛盾しないか参考にする。