resetSseResponseWait and noteRequestProgress silently fail to re-arm the 60s relay timeout if progress tokens arrive as strings

[lowlyocean]

Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

Web

Inspector version

2.2.0

Node version

22.22.0

Operating system (and browser, for the web client)

WSL , Chrome

Transport

Not applicable / never connected

MCP server under inspection

N/A - the timeout toast is shown if the MCP request takes longer than 60 even if progress notifications are sent

Steps to reproduce

Run MCP server that has a long-running tool (>60s) that sends progress notifications less than 60s apart from one another.
Try testing that tool using the MCP Inspector web UI (for a case that takes >60s to complete).

Expected behavior

Progress notifications from the server should not allow the timeout error to display in the web UI.

Actual behavior

Notice the progress notification toasts, but after 60s there will still be a timeout error displayed.

Logs, errors, or screenshots

No response

Already prototyped a fix?

Scan the codebase and find the issue where progressToken is assumed to be numeric instead of string (and also attempt to cast it as a Number). the problem is that when the web client receives progress notifications, they aren't actually resetting the relay timeout of 60s IF those progress notifications code the progressToken as a string (e.g. "4"). Can you spot what I'm referring to?

Before you submit

• I searched existing issues and this is not a duplicate.
• This is not a security vulnerability report (those go through the private advisory process).

[cliffhall]

Triage: Priority Medium (total 7)

• Severity 3: a real feature is broken with no web-side workaround. A progress-reporting tool call on a server that echoes `progressToken` as a string still times out at the relay's flat 60s, because `RemoteSession.requestWaits` / `sseResponseWaits` are keyed by the numeric request id and `"4"` misses `4`. The SDK itself tolerates a string token. (The reporter ran 2.2.0, before Inspector times out when FastMCP tool emits ctx.info/ctx.report_progress (v2.2.0, LEGACY/STDIO) #2028's relay re-arm existed; the string-token gap is still on the 2.8.0 tree.)
• Urgency 3: wanted this milestone. It hits users on the published version, but only with servers that stringify the token.
• Bonuses: +1 `bug` label

Board: #28, Status Incoming (awaiting maintainer review, no milestone yet).

[ShakilUrRehman21]

I’ve implemented a fix for string-valued progress tokens in both RemoteSession.noteRequestProgress() and RemoteClientTransport.resetSseResponseWait(). I added regression tests for both paths.

The changes are pushed to my fork in branch v2/main, commit 8846f0e. Both focused test suites pass, along with Prettier, ESLint, and git diff --check.

GitHub is preventing me from opening a PR because PR creation is restricted to repository collaborators. Would a maintainer be able to open a PR from my fork, or advise on the preferred contribution process?

[cliffhall]

Fixed by #2478 (merged to v2/main).