Skip to content

Sync tool exceeding its timeout returns successful result #5378

Description

@HootRock

A synchronous tool exceeding its configured timeout returns success instead of a timeout error. The timeout docs and #2872 promise timeout errors for sync tools too.

import asyncio
import time
from fastmcp import FastMCP

async def main():
    server = FastMCP()

    @server.tool(timeout=0.03)
    def slow() -> str:
        time.sleep(0.3)
        return "finished after deadline"

    result = await server.call_tool("slow")
    print(result.content)

asyncio.run(main())

Actual: successful TextContent containing finished after deadline. Expected: a timeout error; no thread preemption is assumed. The existing test_sync_timeout_exceeded is skipped.

Reproduced without network requests on main 9488a2619154b7728be80c725fc7473069a1e645, Python 3.12.12, Windows. Investigated with Codex assistance.

Activity

  1. added
    bugSomething isn't working. Reports of errors, unexpected behavior, or broken functionality.
    serverRelated to FastMCP server implementation or server-side functionality.
    on Oct 1, 2026
  2. Jaswanth1902 commented on Oct 2, 2026

    @Jaswanth1902

    Hi @HootRock and maintainers, I’d like to tackle this. I verified the repro where sync worker thread execution ignores the configured timeout parameter and returns successful text content instead of a timeout error. I have a patch that wraps the thread runner future in a strict deadline check returning CallToolResult(isError=True) on expiry, along with un-skipping and passing test_sync_timeout_exceeded. Ready to open a PR.

  3. HootRock commented on Oct 3, 2026

    @HootRock
    ContributorAuthor

    Thanks for verifying the reproduction, @Jaswanth1902! A fix is already available in #5379, opened on October 1, including an enabled test_sync_timeout_exceeded and coverage for dependency lifetime.

    The PR rejects successful results returned after the deadline while still waiting for a synchronous worker to finish, so its dependencies stay alive. It does not preempt the thread or guarantee a response at the deadline. Could you compare your patch with that PR and share any differences or failing cases there? That would help us converge on one repair for maintainers to review.

  4. added a commit that references this issue on Oct 5, 2026
    3e445e0
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

    bugSomething isn't working. Reports of errors, unexpected behavior, or broken functionality.serverRelated to FastMCP server implementation or server-side functionality.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions