resetSseResponseWait and noteRequestProgress silently fail to re-arm the 60s relay timeout if progress tokens arrive as strings
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 75/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript, typescript
Research direction
Look at the code handling progress notifications in the web client, likely in a file related to SSE (Server-Sent Events) or relay timeout management. The issue mentions resetSseResponseWait and noteRequestProgress functions. Search for where progressToken is used and check if it's being cast to a Number. The fix involves ensuring string tokens are properly converted to numbers before resetting the timeout. Test by running a long-running tool that sends string progress tokens and verifying the timeout does not fire.
Written by the indexing model from the issue text.
Description
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).
- Dominant language
- TypeScript
- Stars
- 10.9k
- Forks
- 1.5k
- Avg merge
- 5h 47m
- Merged PRs (30d)
- 148
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from modelcontextprotocol/inspector
-
bug security v2
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
modelcontextprotocol/inspector#2485 · 1 comment ·
-
chore security v2
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
modelcontextprotocol/inspector#2484 · 1 comment ·
-
enhancement v2
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
modelcontextprotocol/inspector#2438 · 1 comment ·
-
bug v2
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
modelcontextprotocol/inspector#2424 · 2 comments ·
-
chore v2
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
modelcontextprotocol/inspector#2416 · 1 comment ·
All issues in modelcontextprotocol/inspector
Similar issues
-
bug(cli): hapi doctor inline-media prints a fabricated B:\ helper-script path in packaged installs Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Crush Open
Difficulty 1/5 Under an hour Newbie friendliness 85/100
catppuccin/catppuccin#3125 ·
-
Add a SECURITY.md Open
Difficulty 1/5 Under an hour Newbie friendliness 90/100
ElementsProject/cln-application#167 · 1 comment · 1 reaction ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Quantco/pnpm-licenses#17 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100