Repository navigation
Stabilize Python streaming resume E2E test - #2597
Conversation
Wait for the detached session lock to release before cold-resuming it from a new CLI process, avoiding a timing race in merge-queue runs. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
The equivalent streaming-disabled cold-resume test remains exposed to the same lock-release race.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review tier: Balanced
Findings: 1
New issues introduced by this change (1)
| Severity | Finding |
|---|---|
 |
python/e2e/test_streaming_fidelity_e2e.py — This wait only protects the streaming-enabled resume path, but… |
What changed in this PR
Stabilizes Python cold-resume streaming tests by waiting for session-lock cleanup before resuming.
Changes:
- Polls
sessions.check_in_useafter disconnect. - Reuses the captured session ID during resume.
| File | Description |
|---|---|
python/e2e/test_streaming_fidelity_e2e.py |
Adds session-lock release synchronization. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Reuse the session-lock release wait before every cold-resume path in the streaming fidelity E2E test. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
SDK Consistency ReviewThis PR only touches No SDK client/public API code is modified, and the
|
A cold-resume E2E run can race the original CLI's asynchronous cleanup after
session.detach, causing the second CLI process to resume while the session lock is still held and eventually time out waiting forsession.idle.Wait for
sessions.check_in_useon the original client to confirm the lock is released before creating the cold-resume client. This retains the existing streaming, cross-client resume, and timeout assertions rather than masking the race with a longer timeout.