You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Fix] Subtask e2e suite can inherit a cancelled delayed mock stream from the previous test (#1074)
* test(e2e): drain delayed mock stream deterministically in subtask suite
The API-hang subtask fixture used aimock's flat latency, which applies
per SSE chunk and is never interrupted by client disconnects, so a
cancelled delayed stream stayed pending server-side for chunks x latency
and could flush into the next test's traffic.
- delay only the first chunk via streamingProfile.ttft so the pending
window is exactly the shared SUBTASK_API_HANG_RESPONSE_LATENCY_MS
- anchor the post-test drain to the request's aimock journal timestamp
and wait out only the remainder of that bounded window
* docs(e2e): clarify subtask drain invariants from code review
---------
Co-authored-by: Roomote <roomote@roomote.dev>
Co-authored-by: Elliott de Launay <edelauna@gmail.com>
Copy file name to clipboardExpand all lines: apps/vscode-e2e/AGENTS.md
+11Lines changed: 11 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -121,6 +121,17 @@ Example:
121
121
122
122
The `model` field can be added to either match when a test targets a specific model.
123
123
124
+
## Delaying a fixture response (simulating a slow or hung provider)
125
+
126
+
Use `streamingProfile: { ttft: <ms> }` on a fixture, not a flat `latency: <ms>`, when a test needs
127
+
to simulate a slow or hung provider (e.g. to cancel an in-flight request mid-stream). `ttft` delays
128
+
only the first SSE chunk, so the pending window is exactly the configured value. Flat `latency`
129
+
delays _every_ chunk, and aimock never observes client disconnects — after a test cancels the
130
+
request, a flat-latency stream keeps flushing chunks server-side for `chunks × latency` before
131
+
reaching the dead socket, which can interleave with the next test's request against the same mock
132
+
server. See `SUBTASK_API_HANG_RESPONSE_LATENCY_MS`in`fixtures/subtasks.ts`for an example,
133
+
including the bounded post-test drain the calling suite uses to wait out that window.
134
+
124
135
## 404 errors in logs are expected
125
136
126
137
Background API calls from the extension (usage collection, initialization) hit aimock with no matching fixture and return 404. These do**not** affect test results — the tests still pass. You'll see `[OpenRouter] API error: { message: '404 No fixture matched' }` in the output; this is normal.
0 commit comments