fix(lifecycle): keep a teardown failure out of the setup check

connectToServer, the initialize SUCCESS push and close() all sat inside
one try, so a close() failure after a completed handshake returned
`server-initialize-setup` and discarded the SUCCESS just recorded. That
is the same misattribution this PR exists to remove, in the scenario it
is named after; prompts.ts, resources.ts and tools.ts already isolate
the connect call.

Isolate connect so only a handshake failure reports as setup. Teardown
is best-effort at this layer to match terminateSessionRaw, which already
swallows the session-terminating DELETE, so the only thing that can
still reject is the client-side close, and that is not a server
conformance result.

Author: rinaldofesta

src/scenarios/server/lifecycle.test.ts

@@ -163,4 +163,20 @@ describe('ServerInitializeScenario', () => {
     // The session-id check is never reached, so no raw fetch is attempted.
     expect(fetchMock).not.toHaveBeenCalled();
   });
+
+  it('keeps the initialize SUCCESS when the client close fails', async () => {
+    fetchMock.mockResolvedValue(new Response(null));
+    closeMock.mockRejectedValueOnce(new Error('transport already closed'));
+
+    const checks = await new ServerInitializeScenario().run(
+      testContext(serverUrl)
+    );
+
+    // Teardown is best-effort, so a close failure must neither retract the
+    // recorded SUCCESS nor be reported as a setup failure (#248).
+    expect(checks).toContainEqual(
+      expect.objectContaining({ id: 'server-initialize', status: 'SUCCESS' })
+    );
+    expect(checks.some((c) => c.id === 'server-initialize-setup')).toBe(false);
+  });
 });

src/scenarios/server/lifecycle.ts

@@ -10,6 +10,7 @@ import {
 import type { RunContext } from '../../connection';
 import {
   connectToServer,
+  type MCPClientConnection,
   reportSetupFailure,
   terminateSessionRaw
 } from '../../connection/sdk-client';
@@ -48,38 +49,44 @@ and validates session ID format if one is assigned.`;
     const { serverUrl } = ctx;
     const checks: ConformanceCheck[] = [];
 
+    let connection: MCPClientConnection;
     try {
-      const connection = await connectToServer(serverUrl, {}, ctx.specVersion);
-
-      // The connection process already does initialization
-      // Check that we have a connected client
-      checks.push({
-        id: 'server-initialize',
-        name: 'ServerInitialize',
-        description:
-          'Server responds to initialize request with valid structure',
-        status: 'SUCCESS',
-        timestamp: new Date().toISOString(),
-        specReferences: [
-          {
-            id: 'MCP-Initialize',
-            url: 'https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle#initialization'
-          }
-        ],
-        details: {
-          serverUrl,
-          connected: true
-        }
-      });
-
-      await connection.close();
+      connection = await connectToServer(serverUrl, {}, ctx.specVersion);
     } catch (error) {
       // The handshake never completed, so neither the initialize check nor the
       // session-id check below can be evaluated. Report a single setup failure
       // rather than mislabeling it as one specific check failing (#248).
       return reportSetupFailure(this.name, error);
     }
 
+    // The connection process already does initialization
+    // Check that we have a connected client
+    checks.push({
+      id: 'server-initialize',
+      name: 'ServerInitialize',
+      description: 'Server responds to initialize request with valid structure',
+      status: 'SUCCESS',
+      timestamp: new Date().toISOString(),
+      specReferences: [
+        {
+          id: 'MCP-Initialize',
+          url: 'https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle#initialization'
+        }
+      ],
+      details: {
+        serverUrl,
+        connected: true
+      }
+    });
+
+    // Teardown on an already-recorded handshake. The session-terminating
+    // DELETE inside close() is best-effort by design (see terminateSessionRaw),
+    // so what can still reject here is the client-side close, which is not a
+    // server conformance result. Keeping it in the connect try above reported
+    // it as `server-initialize-setup` and dropped the SUCCESS just recorded,
+    // which is the misattribution #248 is about.
+    await connection.close().catch(() => {});
+
     // Check: Session ID visible ASCII validation
     // Use a raw fetch to inspect the MCP-Session-Id response header,
     // since the SDK client transport does not expose it.