fix: settle the deliberately in-flight tool calls in the progress tests

[cliffhall]

Closes #1947

Cause

Not a teardown race in InspectorClient.disconnect() — that path already try/catches client.close().

Two tests in inspectorClient.test.ts fire client.callTool(...) without holding the promise (:2224 and :2352), deliberately: they assert on the progress notifications the call streams while it is still in flight. disconnect() then closes the SDK client, which rejects every pending request with Connection closed. With nothing holding the promise, that lands as an unhandled rejection — which vitest counts as a run error, so the run exits 1 with every test passing, aborting ci at coverage and silently skipping verify:build-gate, smoke, and Storybook.

This also explains the environment sensitivity the issue flagged as worth establishing: on a slower machine the tool call completes before the assertions finish, so there is no pending request left for the close to reject and the run is green. Nothing platform-specific about it — just a timing window this machine loses and the GitHub runners happen to win. It is latent on CI, not absent.

Fix

A settleInFlight() helper that attaches the handler at call time — not after the assertions, which would leave a window the rejection can escape through — and returns a promise each test awaits after disconnect() so teardown stays ordered. It asserts neither outcome, since the call may legitimately complete before the teardown or reject with it; asserting either way would reintroduce the same race as a flake.

Per the issue's note, this is not vitest-config-level swallowing: the rejection is handled at the exact call that produced it, and the runtime path is unchanged.

Verification

• clients/web integration file standalone: 140 passed, 0 errors (was 140 passed / 2 errors).
• Full npm run ci from the root: exit 0, all five stages reached — the chain is && and the final Storybook stage ran (110 files / 466 tests). That is the first clean end-to-end run of the gate.

No UI or TUI change, so no screenshots.

Note

Nothing structurally prevents the next fire-and-forget call from reintroducing this. @typescript-eslint/no-floating-promises would catch the class, but it needs type-aware linting turned on for the test globs — worth a separate issue rather than folding into this fix.

[Copilot]

Pull request overview

Handles deliberately in-flight tool calls in progress integration tests to prevent unhandled rejections during disconnect.

Changes:

• Adds an in-flight promise settlement helper.
• Awaits pending calls after disconnect in two progress tests.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

clients/web/src/test/integration/mcp/inspectorClient.test.ts:132

• Re-throwing here rejects the new promise returned by then; that promise has no rejection handler until the later await inFlight. If an unexpected tool failure occurs while the test is still waiting for progress, Node can report it as an unhandled rejection—the same run-level failure this helper is intended to prevent. Attach an immediate observer to the derived promise while still returning it, so the later await continues to fail the test normally.

      throw error;

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

clients/web/src/test/integration/mcp/inspectorClient.test.ts:127

• This accepts every ConnectionClosed failure, not only one caused by the explicit teardown as the helper documents. If the transport closes unexpectedly after emitting the expected progress notifications but before disconnect() starts, all assertions still pass and this branch hides the regression. Track whether teardown has begun (for example, pass a teardown-state predicate/token into the helper and set it immediately before disconnect()), and only absorb ConnectionClosed in that state; otherwise rethrow it like any other call failure.

      if (
        error instanceof SdkError &&
        error.code === SdkErrorCode.ConnectionClosed
      ) {
        return;

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.