Skip to content

feat(client): add SEP-2663 tasks-extension client conformance scenario (issue #374) - #387

Closed
claude[bot] wants to merge 2 commits into
mainfrom
claude/issue-374-tasks-client-scenario
Closed

feat(client): add SEP-2663 tasks-extension client conformance scenario (issue #374)#387
claude[bot] wants to merge 2 commits into
mainfrom
claude/issue-374-tasks-client-scenario

Conversation

@claude

@claudeclaudeBot commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

Requested via Slack thread

The server suite has ten tasks-* scenarios but the client suite had none
(issue #374). Add one client-testing scenario, tasks-client-lifecycle,
in which the harness acts as a task-capable server and observes the
client driving the io.modelcontextprotocol/tasks extension:
- sep-2663-client-handles-polymorphic-result (FAILURE): CreateTaskResult
is recognized and polled to completion via tasks/get; a plain
CallToolResult on the same negotiated session is handled normally.
- sep-2663-client-emits-mcp-name-on-tasks-methods (FAILURE): every
tasks/get, tasks/update, tasks/cancel POST stamps Mcp-Name with
params.taskId (SEP-2243 routing headers).
- sep-2663-client-honors-poll-interval (WARNING): consecutive polls of
the same task respect pollIntervalMs, gated on the early side only so
slow CI cannot flake it. Un-excluded from sep-2663.yaml accordingly.
- sep-2663-cancel-not-via-cancelled-notification (FAILURE): the running
task is cancelled via tasks/cancel, never notifications/cancelled.
- sep-2663-client-rejects-task-result-on-unsupported (FAILURE): a
CreateTaskResult returned to ping is treated as an invalid response,
not driven as a real task.
- Flow gates: tasks-client-extension-declared and
tasks-client-terminal-failed-surfaced (failed tasks are surfaced and
the flow continues instead of polling the terminal task forever).
A client that never declares the extension capability (initialize
capabilities.extensions or per-request _meta clientCapabilities) has
not opted into the optional extension: all checks report SKIPPED. A
client that never sends any request fails via untestableCheck.
The scenario is registered in the client-testing list and the
extensions suite (now derived from source.extensionId). The
everything-client gains a conforming handler, and the vitest suite
covers the positive path plus one negative case per check.
Addresses #374
@pkg-pr-new

pkg-pr-newBot commented Jul 2, 2026

Copy link
Copy Markdown

Open in StackBlitz

npx https://pkg.pr.new/@modelcontextprotocol/conformance@387

commit: f682a6f

- Drop the poll-cadence anchor when tasks/cancel is observed so a prompt
confirming tasks/get after cancellation is no longer measured against
the last working poll (false early-poll WARNING); regression-tested
with a poll -> cancel -> immediate-confirm conforming client, and the
everything-client now exercises that exact sequence.
- Only flag notifications/cancelled that actually target a task (by the
originating tools/call request id or a reason referencing a known
taskId); unrelated request cancellation is legal and recorded in
details only, with a test proving it stays SUCCESS.
- Move the 'client never issued tasks/cancel' arm off the SEP-traced
sep-2663-cancel-not-via-cancelled-notification id into a dedicated
flow gate, tasks-client-cancel-flow-completed (registered in the
declared-ID list and the yaml flow-gate comment block); the untouched
MUST NOT id now reports untestable when cancellation was never
attempted.
- initialize reply carries resultType:'complete' and clamps
protocolVersion to NEGOTIABLE_PROTOCOL_VERSIONS instead of echoing
arbitrary values.
- tasks/update rejects unknown taskIds with -32602, matching
tasks/cancel.
- FAILURE-path tests for both remaining flow gates: a client that keeps
polling the failed task, one that stops dead after it, and one that
never cancels.
- everything-client _meta merge spreads caller _meta first so the tasks
capability entry stays authoritative.
- Reword the timing-comparison comments: this check is the early-side
half of the sse-retry timing approach (sse-retry gates both sides);
document the cadence anchor (response-send to next-request-arrival)
and why 50ms tolerance suffices in-host.
@claudeclaudeBot closed this Jul 2, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@claude