Skip to content

fix: fall back to legacy initialize on general errors - #1088

Open
jamadeo wants to merge 1 commit into
mainfrom
jamadeo/legacy-fallback-lifecycle-mode
Open

fix: fall back to legacy initialize on general errors#1088
jamadeo wants to merge 1 commit into
mainfrom
jamadeo/legacy-fallback-lifecycle-mode

Conversation

@jamadeo

@jamadeo jamadeo commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

fixes #1040

Motivation and Context

The fallback logic was too strict, only falling back on a single METHOD_NOT_FOUND error, while the spec states we should fall back on any error that does not indicate a modern server.

How Has This Been Tested?

Tested against FastMCP+goose

Breaking Changes

No

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

@jamadeo
jamadeo requested a review from a team as a code owner July 29, 2026 22:57
@github-actions github-actions Bot added T-test Testing related changes T-core Core library changes T-service Service layer changes labels Jul 29, 2026
// On stdio, legacy servers may reject an unknown pre-initialize request with
// any implementation-defined error (or not respond at all). Treat every
// failure not recognized as modern version negotiation as a legacy peer.
Err(_) => {

@DaleSeo DaleSeo Jul 29, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also consider this in the issue?
Image

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fix might not be quite as straightforward as I'd hoped. The core of the issue is

A client that needs to interoperate with both kinds of servers detects the server’s era with transport-specific mechanics, specified in the binding pages:

  • stdio: probe with server/discover and fall back on any error that is not a recognized modern error.
  • Streamable HTTP: attempt a modern request and inspect the body of a 400 Bad Request before falling back.

from here

so, I think the proper fix will need to implement this slightly differently.

}

#[tokio::test]
async fn auto_startup_falls_back_after_discover_invalid_params() {

@DaleSeo DaleSeo Jul 29, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be worth adding a test to catch a future ClientInitializeError variant being silently swept into Err(_)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

T-core Core library changes T-service Service layer changes T-test Testing related changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ClientLifecycleMode::Auto does not fall back for deployed legacy-server responses

2 participants