Skip to content

Progress notifications not delivered via SSE in stateless HTTP mode #2001

Closed
Closed
Progress notifications not delivered via SSE in stateless HTTP mode#2001
Labels
P2Moderate issues affecting some users, edge cases, potentially valuable featurebugSomething isn't workingready for workEnough information for someone to start working on

Description

@hubbard-zlee
hubbard-zlee
opened on Feb 5, 2026

Initial Checks

Description

Summary

Context.report_progress() notifications are not delivered to clients when using the streamable HTTP transport, while Context.info() and other logging methods work correctly.

Root Cause

In src/mcp/server/fastmcp/server.py, the report_progress method does not pass related_request_id to send_progress_notification():

async def report_progress(self, progress: float, total: float | None = None, message: str | None = None) -> None:
    progress_token = self.request_context.meta.progressToken if self.request_context.meta else None

    if progress_token is None:
        return

    await self.request_context.session.send_progress_notification(
        progress_token=progress_token,
        progress=progress,
        total=total,
        message=message,
        # related_request_id is missing here
    )

The SSE transport uses related_request_id in the message metadata to route notifications to the correct client. Without it, progress notifications are silently dropped.

In contrast, send_log_message (used by info(), warning(), etc.) correctly passes related_request_id:

Fix

Add related_request_id=self.request_id to the send_progress_notification() call:

await self.request_context.session.send_progress_notification(
    progress_token=progress_token,
    progress=progress,
    total=total,
    message=message,
    related_request_id=self.request_id,
)

Reproduction

  1. Create a FastMCP server with stateless_http=True
  2. In a tool, call both await ctx.info("test") and await ctx.report_progress(0.5, total=1.0, message="test")
  3. Observe that info() messages are delivered via SSE but report_progress() messages are not

Environment

  • MCP SDK version: 1.26.0
  • Python version: 3.11
  • Transport: Streamable HTTP (stateless_http=True)

Example Code



Python & MCP Python SDK


- MCP SDK version: 1.26.0
- Python version: 3.11

Activity
  1. maxisbey
    added 
    bugSomething isn't working
     
    P2Moderate issues affecting some users, edge cases, potentially valuable feature
     
    ready for workEnough information for someone to start working on
     on Feb 10, 2026
  2. weiguangli-io
    added a commit that references this issue on Mar 4, 2026
    fix: pass related_request_id in Context.report_progress()
    6459c61
  3. koriyoshi2041 commented on May 30, 2026 
    @koriyoshi2041
    koriyoshi2041
    on May 30, 2026
    I checked this against current main (616476f) and the originally described missing related_request_id path appears to be fixed now.
    

    Evidence:
    

      

    • Context.report_progress() in src/mcp/server/mcpserver/context.py now passes related_request_id=self.request_id to send_progress_notification().
      • 

    • The direct regression test passes locally:

        

      • uv run pytest tests/server/mcpserver/test_server.py::test_report_progress_passes_related_request_id -q
        • 

      

      • 

    • I also ran a small stateless streamable HTTP check with connect_over_streamable_http(..., stateless_http=True): a tool calling ctx.report_progress(1, 3) and ctx.report_progress(2, 3, "halfway") delivered both progress callbacks before returning.
      • 

    

    Unless there is a remaining case beyond stateless streamable HTTP progress callback delivery, this may be closable.
  4. shivamsingh-007 commented on Jul 12, 2026 
    @shivamsingh-007
    shivamsingh-007
    on Jul 12, 2026
    Confirmed via independent analysis. On \main\ (v2), the code path was completely refactored — \Context.report_progress()\ now routes through _request_outbound.progress()\ (_SingleExchangeDispatchContext), which is inherently request-scoped via its own SSE sink (\src/mcp/server/_streamable_http_modern.py:113-121). No 
    
elated_request_id\ needed because the channel is the request's own channel. All 47 progress-related tests pass across all transport modes including \streamable-http-stateless. Agree this is closable.
  5. shivamsingh-007 commented on Jul 12, 2026 
    @shivamsingh-007
    shivamsingh-007
    on Jul 12, 2026
    Apologies for the comment noise on this issue. The earlier comments were redundant — #2001 is already resolved (confirmed on main at 616476f, with a test at #2747). No further action needed.
  6. kuotunyu commented on Jul 25, 2026 
    @kuotunyu
    kuotunyu
    on Jul 25, 2026
    v1.x has the same fix now: #2994 (commit 9678a3b3, merged 2026-06-26) adds related_request_id=self.request_id to Context.report_progress() in src/mcp/server/fastmcp/server.py, and updates tests/issues/test_176_progress_token.py to assert it. The comments above cover main; the v1.x side does not seem to have been noted here yet.
    

    The part that may still matter for this issue: the fix is not in any published 1.x release.
    


    Checked against the released source rather than the branch: at tags v1.28.0 and v1.28.1, report_progress() calls send_progress_notification() without related_request_id. So an mcp>=1.28.1,<2.0 constraint still resolves to the pre-fix behavior.
    

    For anyone landing here on 1.28.x, the workaround is to bypass ctx.report_progress() and pass the field the fix adds:
    

    progress_token = ctx.request_context.meta.progressToken if ctx.request_context.meta else None
if progress_token is not None:
    await ctx.session.send_progress_notification(
        progress_token=progress_token,
        progress=progress,
        total=total,
        message=message,
        related_request_id=ctx.request_id,
    )
    

    Confirmed on 1.28.1 with the official client SDK's progress_callback over both stdio and Streamable HTTP.
    

    Is a 1.x patch release including #2994 planned? That would let downstream consumers drop the workaround instead of pinning to a git ref.
    

    Separately: #2207 targets v1.x with the same change and is still open, so it looks superseded by #2994.
  7. maxisbey commented on Jul 29, 2026 
    @maxisbey
    maxisbey
    on Jul 29, 2026
    Contributor
    Thanks for the report. Closing this as it's been fixed in v2, which is now released (see #2038), and as noted above the same fix landed on the 1.x line via #2994. If you still run into this on v2, feel free to reopen.
    

    AI Disclaimer
  8. maxisbey
    closed this as completedon Jul 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Metadata
Assignees
No one assigned
    Labels
    P2Moderate issues affecting some users, edge cases, potentially valuable featurebugSomething isn't workingready for workEnough information for someone to start working on
    Type
    No type
    Projects
    No projects
      Milestone
      No milestone
      Relationships
      None yet
      Development
      No branches or pull requests
      Issue actions