Fix keep_alive passthrough in StdioMCPServer.to_transport() by jlowin · Pull Request #2791 · PrefectHQ/fastmcp

jlowin · 2026-01-02T03:55:13Z

Fixes a bug where StdioMCPServer.to_transport() was not passing through the keep_alive parameter to the created StdioTransport, causing subprocesses to persist after the Client context manager exits even when keep_alive=False was specified.

Changes

Added keep_alive: bool | None = None field to StdioMCPServer class
Updated to_transport() method to pass keep_alive=self.keep_alive when creating StdioTransport
Added comprehensive test coverage for the passthrough behavior

Example

from fastmcp.mcp_config import StdioMCPServer

# Now works correctly - keep_alive is passed through
server = StdioMCPServer(command='test', keep_alive=False)
transport = server.to_transport()
assert transport.keep_alive == False  # ✓ Now correctly False

Previously, transport.keep_alive would always be True regardless of the value set on StdioMCPServer.

coderabbitai · 2026-01-02T03:59:14Z

Walkthrough

A new optional field keep_alive: bool | None was added to the StdioMCPServer class in src/fastmcp/mcp_config.py, with a default value of None. This field controls whether the subprocess remains alive between connections. The to_transport method was updated to pass the keep_alive value to StdioTransport during its instantiation.

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description provides clear context about the bug, lists the changes made, and includes a practical example; however, it does not include the required checklist items from the template.	Add the Contributors Checklist and Review Checklist items to the description, including issue reference and verification that manual testing and documentation updates were completed.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: adding keep_alive parameter passthrough in StdioMCPServer.to_transport() method.
Docstring Coverage	✅ Passed	Docstring coverage is 91.67% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

📝 Generate docstrings

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between eb16de6 and e63d670.

📒 Files selected for processing (1)

src/fastmcp/mcp_config.py

🚧 Files skipped from review as they are similar to previous changes (1)

src/fastmcp/mcp_config.py

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)

GitHub Check: Run tests: Python 3.10 on windows-latest
GitHub Check: Run tests: Python 3.13 on ubuntu-latest
GitHub Check: Run tests: Python 3.10 on ubuntu-latest
GitHub Check: Run tests with lowest-direct dependencies

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

coderabbitai

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/fastmcp/server/middleware/error_handling.py (1)
81-112: Potential bug: wrapped McpError cause falls through to generic internal error.

When error.__cause__ is an McpError, the isinstance check on line 83 passes only for the wrapper exception, not the cause. Since McpError isn't in any of the explicit type checks (lines 92-108), it falls through to the generic "Internal error" on line 110, discarding the original McpError's code and message.

Additionally, there's an inconsistency: error_type is derived from the cause, but all error messages use error!s (the wrapper's string). This could produce confusing responses where the error code implies one issue (e.g., "Invalid params") but the message describes something else.

Consider either:

Checking if error.__cause__ is an McpError and returning it directly, or

Using consistent sources for both type and message.
🔎 Suggested fix to handle McpError causes
     def _transform_error(self, error: Exception) -> Exception:
         """Transform non-MCP errors to proper MCP errors."""
         if isinstance(error, McpError):
             return error
 
+        # If the cause is an McpError, return it directly
+        if isinstance(error.__cause__, McpError):
+            return error.__cause__
+
         if not self.transform_errors:
             return error
 
         # Map common exceptions to appropriate MCP error codes
         error_type = type(error.__cause__) if error.__cause__ else type(error)
+        # Use cause's message for consistency when using cause's type
+        error_source = error.__cause__ if error.__cause__ else error
Then replace {error!s} with {error_source!s} in the error messages below.

🧹 Nitpick comments (6)

docs/getting-started/installation.mdx (1)

26-28: Consider if duplicate warnings are necessary.

This warning about FastMCP 3.0 development is clear and actionable, which is good. However, according to the AI summary, the same warning appears in docs/getting-started/welcome.mdx (twice in that file).

Having the same warning on multiple onboarding pages may be excessive and could create maintenance burden if the message needs to be updated. Consider consolidating these warnings or ensuring they serve different purposes in each location.

As per coding guidelines: MDX documentation should avoid redundancy and maintain consistency across pages.

docs/docs.json (1)

15-15: Time-sensitive banner content will need updating.

The banner now promotes the PyAI Conf on March 10th. After this date, the banner will be outdated. Consider creating a follow-up task to update or remove this banner after the event.
src/fastmcp/server/auth/auth.py (1)
307-332: Consider applying the set_mcp_path pattern consistently across provider types.

OAuthProvider.get_routes() now calls set_mcp_path() and uses the stored self._resource_url (line 481), while RemoteAuthProvider.get_routes() still computes the resource URL locally with self._get_resource_url(mcp_path) (line 318).

This inconsistency isn't a bug, but applying the pattern uniformly would improve maintainability.
🔎 Optional refactor to align RemoteAuthProvider with the new pattern
 def get_routes(
     self,
     mcp_path: str | None = None,
 ) -> list[Route]:
     """Get routes for this provider.
     
     Creates protected resource metadata routes (RFC 9728).
     """
+    # Configure resource URL before creating routes
+    self.set_mcp_path(mcp_path)
+    
     routes = []

-    # Get the resource URL based on the MCP path
-    resource_url = self._get_resource_url(mcp_path)
-
-    if resource_url:
+    if self._resource_url:
         # Add protected resource metadata routes
         routes.extend(
             create_protected_resource_routes(
-                resource_url=resource_url,
+                resource_url=self._resource_url,
                 authorization_servers=self.authorization_servers,
                 scopes_supported=self.token_verifier.required_scopes,
                 resource_name=self.resource_name,
                 resource_documentation=self.resource_documentation,
             )
         )

     return routes
Also applies to: 426-427, 473-485
docs/integrations/supabase.mdx (1)
40-42: Clarify when auth_route parameter is needed.

The inline comment "if self-hosting and using custom routes" suggests this parameter is conditional, but the code example shows it as part of the standard configuration. Consider either:

Moving this parameter to a separate example specifically for self-hosted scenarios, or

Showing it as an optional parameter with a comment that it defaults to "/auth/v1"

This would help users understand they can omit this parameter for standard Supabase Cloud deployments.
🔎 Suggested documentation structure
 # Configure Supabase Auth
 auth = SupabaseProvider(
     project_url="https://abc123.supabase.co",
     base_url="http://localhost:8000",
-    auth_route="/my/auth/route" # if self-hosting and using custom routes
 )
Then add a separate note or example:
**For self-hosted Supabase with custom auth routes:**

If you're self-hosting Supabase Auth with a custom route, specify it:

\```python
auth = SupabaseProvider(
    project_url="https://your-instance.com",
    base_url="http://localhost:8000",
    auth_route="/my/auth/route"  # defaults to "/auth/v1"
)
\```
src/fastmcp/prompts/prompt_manager.py (1)
110-111: LGTM!

The FastMCPError propagation is implemented correctly and aligns with the error handling pattern in dependencies.py. This ensures proper error categorization throughout the call stack.

Consider adding a clarifying comment similar to dependencies.py for consistency:
         except FastMCPError:
+            # Let FastMCPError subclasses (ToolError, ResourceError, etc.)
+            # propagate unchanged so they can be handled appropriately
             raise
src/fastmcp/server/server.py (1)
479-480: Consider adding a timeout for robustness.

The simplified cleanup with suppress(asyncio.CancelledError) is cleaner than a timeout-based approach. However, if the worker task doesn't respect cancellation (e.g., due to a bug or blocking operation), this will block indefinitely during shutdown.

Consider using asyncio.wait_for() with a generous timeout as a safety net:
🔎 Proposed enhancement
                            finally:
                                worker_task.cancel()
-                               with suppress(asyncio.CancelledError):
-                                   await worker_task
+                               try:
+                                   with suppress(asyncio.CancelledError):
+                                       await asyncio.wait_for(worker_task, timeout=30.0)
+                               except asyncio.TimeoutError:
+                                   logger.warning(
+                                       f"Worker task did not stop within 30s after cancellation"
+                                   )

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 38ec476 and eb16de6.

⛔ Files ignored due to path filters (18)

README.md is excluded by none and included by none
pyproject.toml is excluded by none and included by none
tests/client/test_elicitation.py is excluded by none and included by none
tests/client/test_sse.py is excluded by none and included by none
tests/client/test_streamable_http.py is excluded by none and included by none
tests/client/transports/test_uv_transport.py is excluded by none and included by none
tests/server/auth/providers/test_supabase.py is excluded by none and included by none
tests/server/auth/test_oauth_proxy.py is excluded by none and included by none
tests/server/middleware/test_error_handling.py is excluded by none and included by none
tests/server/openapi/test_comprehensive.py is excluded by none and included by none
tests/server/tasks/test_server_tasks_parameter.py is excluded by none and included by none
tests/server/tasks/test_task_methods.py is excluded by none and included by none
tests/server/test_dependencies.py is excluded by none and included by none
tests/server/test_logging.py is excluded by none and included by none
tests/test_mcp_config.py is excluded by none and included by none
tests/tools/test_tool.py is excluded by none and included by none
tests/utilities/test_json_schema.py is excluded by none and included by none
uv.lock is excluded by !**/*.lock and included by none

📒 Files selected for processing (23)

docs/changelog.mdx
docs/docs.json
docs/getting-started/installation.mdx
docs/getting-started/welcome.mdx
docs/integrations/supabase.mdx
docs/updates.mdx
examples/auth/github_oauth/client.py
src/fastmcp/mcp_config.py
src/fastmcp/prompts/prompt_manager.py
src/fastmcp/resources/resource_manager.py
src/fastmcp/server/auth/auth.py
src/fastmcp/server/auth/oauth_proxy.py
src/fastmcp/server/auth/providers/supabase.py
src/fastmcp/server/dependencies.py
src/fastmcp/server/elicitation.py
src/fastmcp/server/middleware/error_handling.py
src/fastmcp/server/openapi/components.py
src/fastmcp/server/server.py
src/fastmcp/tools/tool.py
src/fastmcp/tools/tool_manager.py
src/fastmcp/utilities/cli.py
src/fastmcp/utilities/json_schema.py
src/fastmcp/utilities/openapi/schemas.py

🧰 Additional context used

📓 Path-based instructions (4)

src/fastmcp/**/*.py

📄 CodeRabbit inference engine (AGENTS.md)

src/fastmcp/**/*.py: Python ≥ 3.10 with full type annotations required
Prioritize readable, understandable code - clarity over cleverness. Avoid obfuscated or confusing patterns even if shorter
Follow existing patterns and maintain consistency in code implementation
Be intentional about re-exports - don't blindly re-export everything to parent namespaces. Core types defining a module's purpose should be exported. Specialized features can live in submodules. Only re-export to fastmcp.* for most fundamental types
Never use bare except - be specific with exception types

Files:

src/fastmcp/server/dependencies.py
src/fastmcp/server/server.py
src/fastmcp/utilities/json_schema.py
src/fastmcp/mcp_config.py
src/fastmcp/server/middleware/error_handling.py
src/fastmcp/server/auth/providers/supabase.py
src/fastmcp/server/elicitation.py
src/fastmcp/server/auth/auth.py
src/fastmcp/utilities/openapi/schemas.py
src/fastmcp/resources/resource_manager.py
src/fastmcp/prompts/prompt_manager.py
src/fastmcp/tools/tool.py
src/fastmcp/tools/tool_manager.py
src/fastmcp/utilities/cli.py
src/fastmcp/server/openapi/components.py
src/fastmcp/server/auth/oauth_proxy.py

docs/**/*.{md,mdx,json}

📄 CodeRabbit inference engine (AGENTS.md)

Documentation uses Mintlify framework. Files must be in docs.json to be included. Never modify docs/python-sdk/** (auto-generated)

Files:

docs/docs.json
docs/getting-started/welcome.mdx
docs/updates.mdx
docs/getting-started/installation.mdx
docs/changelog.mdx
docs/integrations/supabase.mdx

docs/**/*.mdx

📄 CodeRabbit inference engine (docs/.cursor/rules/mintlify.mdc)

docs/**/*.mdx: Use clear, direct language appropriate for technical audiences
Write in second person ('you') for instructions and procedures in MDX documentation
Use active voice over passive voice in MDX technical documentation
Employ present tense for current states and future tense for outcomes in MDX documentation
Maintain consistent terminology throughout all MDX documentation
Keep sentences concise while providing necessary context in MDX documentation
Use parallel structure in lists, headings, and procedures in MDX documentation
Lead with the most important information using inverted pyramid structure in MDX documentation
Use progressive disclosure in MDX documentation: present basic concepts before advanced ones
Break complex procedures into numbered steps in MDX documentation
Include prerequisites and context before instructions in MDX documentation
Provide expected outcomes for each major step in MDX documentation
End sections with next steps or related information in MDX documentation
Use descriptive, keyword-rich headings for navigation and SEO in MDX documentation
Focus on user goals and outcomes rather than system features in MDX documentation
Anticipate common questions and address them proactively in MDX documentation
Include troubleshooting for likely failure points in MDX documentation
Provide multiple pathways (beginner vs advanced) but offer an opinionated path to avoid overwhelming users in MDX documentation
Always include complete, runnable code examples that users can copy and execute in MDX documentation
Show proper error handling and edge case management in MDX code examples
Use realistic data instead of placeholder values in MDX code examples
Include expected outputs and results for verification in MDX code examples
Test all code examples thoroughly before publishing in MDX documentation
Specify language and include filename when relevant in MDX code examples
Add explanatory comments for complex logic in MDX code examples
Document all API...

Files:

docs/getting-started/welcome.mdx
docs/updates.mdx
docs/getting-started/installation.mdx
docs/changelog.mdx
docs/integrations/supabase.mdx

docs/**/*.{md,mdx}

📄 CodeRabbit inference engine (AGENTS.md)

docs/**/*.{md,mdx}: Code examples in documentation must explain before showing code and make blocks fully runnable (include imports)
Documentation structure: Headers form navigation guide with logical H2/H3 hierarchy. Content should be user-focused with sections motivating features (why) before mechanics (how). Use prose over code comments for important information
Never use 'This isn't...' or 'not just...' constructions in writing - state what something IS directly. Avoid defensive writing patterns

Files:

docs/getting-started/welcome.mdx
docs/updates.mdx
docs/getting-started/installation.mdx
docs/changelog.mdx
docs/integrations/supabase.mdx

🧠 Learnings (14)

📓 Common learnings

Learnt from: CR
Repo: jlowin/fastmcp PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-25T15:53:07.656Z
Learning: Applies to tests/**/*.py : Pass FastMCP servers directly to clients for testing without network complexity; only use HTTP transport when explicitly testing network features

Learnt from: jlowin
Repo: jlowin/fastmcp PR: 0
File: :0-0
Timestamp: 2025-12-01T15:48:05.095Z
Learning: PR #2505 in fastmcp adds NEW functionality to get_access_token(): it now first checks request.scope["user"] for the token (which never existed before), then falls back to _sdk_get_access_token() (the only thing the original code did). This is not a reversal of order but entirely new functionality to fix stale token issues.