fix: call tasks/result when task status is input_required

[galagaevdc]

Summary

Fixes #1073

Per the MCP spec https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks#input-required-status, when a client observes input_required status during task polling it must call tasks/result to give the server a chance to deliver queued elicitation/sampling requests. Previously the polling loop only called tasks/result after completed status, leaving the server unable to trigger elicitation.

After elicitation is handled the task transitions back to working so taskCompleted is not set — polling continues until a terminal status is reached.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Documentation update
• Refactoring (no functional changes)
• Test updates
• Build/CI improvements

Changes Made

The fix adds an explicit input_required branch in the polling loop that calls tasks/result as required by the
https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks#input-required-status. After elicitation is handled the server transitions the task back to working, so the loop
continues polling until a terminal status is reached.

Related Issues

#1073

Testing

• Tested in UI mode
• Tested in CLI mode
• Tested with STDIO transport
• Tested with SSE transport
• Tested with Streamable HTTP transport
• Added/updated automated tests
• Manual testing performed

Test Results and/or Instructions

Screenshots are encouraged to share your testing results for this change.

Checklist

• Code follows the style guidelines (ran npm run prettier-fix)
• Self-review completed
• Code is commented where necessary
• Documentation updated (README, comments, etc.)

Breaking Changes

None

[cliffhall]

Reviewed and tested locally: rebased cleanly on main (v0.22.0), builds, the new App.taskPolling.test.tsx passes, and I exercised the flow against the server-everything task PR (modelcontextprotocol/servers#3816) — the input_required → elicitation hand-off works end-to-end. 👍

The core change is correct and the added test coverage is appreciated. Two robustness points worth considering before merge (left as inline comments):

1. Repeated tasks/result while input_required persists — the branch doesn't terminate the poll loop, so if the task reports input_required across multiple polls, tasks/result is re-issued each interval with no guard. Could redeliver duplicate elicitation/sampling requests. Gating on the transition into input_required would avoid that. (Also: the awaited response is discarded here, unlike the completed branch.)

2. Error handling — the new tasks/result call shares the loop's try, whose catch ends polling and shows an error. A server that rejects tasks/result on a non-completed task would cause the inspector to abandon the task instead of continuing to poll. Catching this specific call locally would be more resilient.

Neither blocks the happy path I tested; they're about behavior against slower or stricter task servers.

[cliffhall]

LGTM! 👍

All tests and checks pass locally with this PR branch rebased against main. Tested manually against server-everything at PR #3816

[cliffhall]

Thanks for this, @galagaevdc