handleAutomaticTaskPolling ignores AbortSignal; cancelled requests poll indefinitely

[blackwell-systems]

Initial Checks

• Using the latest version of MCP TypeScript SDK
• Searched existing issues

Description

In packages/server/src/server/mcp.ts, handleAutomaticTaskPolling contains a while loop (lines 328-335) that polls a task store until completion. The loop never checks ctx.mcpReq.signal.aborted. If the client cancels the request, the poll loop continues consuming server resources indefinitely.

while (task.status !== 'completed' && task.status !== 'failed' && task.status !== 'cancelled') {
    await new Promise(resolve => setTimeout(resolve, pollInterval));
    const updatedTask = await ctx.task.store.getTask(taskId);
    // ...
}

The taskManager.ts implementation of the same pattern correctly checks the signal (line 856):

if (signal.aborted) {
    resolver(new ProtocolError(ProtocolErrorCode.InternalError, 'Task cancelled or completed'));
    break;
}

Impact

On multi-tenant servers, a single cancelled long-running tool leaks a polling loop per cancelled request. Over time this accumulates.

Suggested fix

while (task.status !== 'completed' && task.status !== 'failed' && task.status !== 'cancelled') {
    if (ctx.mcpReq.signal.aborted) {
        throw new ProtocolError(ProtocolErrorCode.RequestCancelled, 'Request cancelled during task polling');
    }
    await new Promise(resolve => setTimeout(resolve, pollInterval));
    // ...
}

[mcp-claude]

the file path packages/server/src/server/mcp.ts and the handleAutomaticTaskPolling function no longer exist on main — the 2025-11 experimental tasks feature (TaskManager, ctx.task, taskStore, the polling wrapper) was removed in c8d7401 (PR #2128, SEP-2663). tested against 9b41b56.

the described defect is real on v1.x though: src/server/mcp.ts:387-394 polls extra.taskStore.getTask(taskId) on pollInterval and never checks extra.signal.aborted (the actual field name; the issue's ctx.mcpReq.signal.aborted is not the v1.x API). reproduced against 69749aa — after the client aborts, the server continues polling the task store on the poll interval.

if v1.x still needs a backport, reopen on the v1.x tracking issue; otherwise migration to v2 is the fix.

repro (v1.x)

// repro.ts
import { z } from 'zod';
import { McpServer } from './src/server/mcp.js';
import { Client } from './src/client/index.js';
import { InMemoryTaskStore } from './src/experimental/tasks/stores/in-memory.js';
import { InMemoryTransport } from './src/inMemory.js';
import { CallToolResultSchema } from './src/types.js';

async function main() {
    const rawStore = new InMemoryTaskStore();
    const pollCounter = { count: 0 };
    const originalGetTask = rawStore.getTask.bind(rawStore);
    (rawStore as any).getTask = async (id: string) => {
        pollCounter.count += 1;
        return originalGetTask(id);
    };

    const mcpServer = new McpServer(
        { name: 'repro-server', version: '1.0' },
        {
            capabilities: { tools: {}, tasks: { requests: { tools: { call: {} } } } },
            taskStore: rawStore
        }
    );
    const client = new Client(
        { name: 'repro-client', version: '1.0' },
        { capabilities: { tasks: { requests: { tools: { call: {} } } } } }
    );

    mcpServer.experimental.tasks.registerToolTask(
        'never-completes',
        { description: 't', inputSchema: { value: z.number() }, execution: { taskSupport: 'optional' } },
        {
            createTask: async (_a, extra) => {
                const task = await extra.taskStore.createTask({ ttl: 60000, pollInterval: 100 });
                return { task };
            },
            getTask: async (_a, extra) => (await extra.taskStore.getTask(extra.taskId))!,
            getTaskResult: async (_a, extra) => (await extra.taskStore.getTaskResult(extra.taskId)) as any
        }
    );

    const [cT, sT] = InMemoryTransport.createLinkedPair();
    await Promise.all([client.connect(cT), mcpServer.connect(sT)]);

    const abort = new AbortController();
    const p = client.callTool({ name: 'never-completes', arguments: { value: 1 } }, CallToolResultSchema,
        { signal: abort.signal }).catch(e => `err: ${e?.message || e}`);

    await new Promise(r => setTimeout(r, 600));
    const before = pollCounter.count;
    abort.abort();
    await new Promise(r => setTimeout(r, 1000));
    const after = pollCounter.count;
    console.log(`polls before cancel: ${before}`);
    console.log(`polls 1s after cancel: ${after}`);
    console.log(`delta after cancel: ${after - before}`);
    console.log('client result:', await p);
    rawStore.cleanup();
}
main();

$ npx tsx repro.ts
polls before cancel: 5
client aborted at t=600ms
polls 1s after cancel: 15
delta after cancel: 10
polling loop leaked after cancel: YES (bug)
client result: client-error: MCP error -32001: AbortError: This operation was aborted

client sees AbortError, but server keeps polling taskStore.getTask on the interval — 10 additional polls in 1s at pollInterval=100.

code path on v1.x (src/server/mcp.ts):

• tools/call handler L177 → detects taskSupport === 'optional' L208 → calls handleAutomaticTaskPolling(tool, request, extra) L209
• L387-394 loops on task.status !== 'completed' && ... !== 'failed' && ... !== 'cancelled', await sleep(pollInterval), extra.taskStore.getTask(taskId)
• no extra.signal.aborted check anywhere in the loop; cancellation aborts the client's outbound request but the server-side loop keeps calling getTask

on main this whole codepath is gone (commit c8d7401, PR #2128).