Skip to content

Integration suite exits non-zero on two unhandled CONNECTION_CLOSED rejections from InspectorClient.disconnect #1973

Description

@cliffhall

What happens

clients/web npm run test:coverage (and therefore the root npm run coverage, and CI) exits non-zero even though every test passes:

 Test Files  315 passed (315)
      Tests  4887 passed (4887)
     Errors  2 errors

The two errors are unhandled promise rejections raised during transport teardown:

⎯⎯⎯⎯ Unhandled Rejection ⎯⎯⎯⎯⎯
SdkError: Connection closed
 ❯ Client._onclose .../shared/protocol.ts:839:23
 ❯ StreamableHTTPClientTransport._transport.onclose .../shared/protocol.ts:790:22
 ❯ StreamableHTTPClientTransport.close .../client/streamableHttp.ts:890:18
 ❯ MessageTrackingTransport.close core/mcp/messageTrackingTransport.ts:110:31
 ❯ Client.close .../shared/protocol.ts:1226:32
 ❯ InspectorClient.disconnect core/mcp/inspectorClient.ts:2126:29
 ❯ src/test/integration/mcp/inspectorClient.test.ts:2264:21
Serialized Error: { code: 'CONNECTION_CLOSED', data: undefined }

The second is the same shape from inspectorClient.test.ts:2382. Vitest attributes them to should not dispatch progressNotification events when progress is disabled and should complete when timeout and resetTimeoutOnProgress are set (options passed through).

To reproduce

cd clients/web
npx vitest run --project=integration src/test/integration/mcp/inspectorClient.test.ts
# EXIT=1, 2 unhandled rejections, 0 failing tests

Reproduces standalone, so it is not a cross-file interaction.

Expected

disconnect() closing a streamable-HTTP transport should not leave a rejected promise unattended. Either the in-flight request rejection is awaited/caught inside InspectorClient.disconnect (or MessageTrackingTransport.close), or the test awaits it — so the suite exits 0 when all tests pass.

Why it matters

A green test list with a red exit code is the worst of both worlds: CI fails without naming a failing test, and the natural response is to assume flake and re-run. It also masks any real unhandled rejection that appears later, since the baseline is already two.

Context

Found while verifying #1888 (PR #1972). Confirmed present on v2/main and independent of that change, which touches only clients/web/src/components/groups/SchemaForm.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingv2Issues and PRs for v2

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions