fix(auth): preserve OAuth discovery transport errors by tjni · Pull Request #1028 · modelcontextprotocol/rust-sdk

tjni · 2026-07-22T21:05:42Z

Motivation and Context

OAuth discovery currently treats network and server failures as missing metadata, which can incorrectly make a server appear not to support OAuth even when the root cause could be a client-side issue or a server-side server error.

This change propagates such errors to clients so that they can be displayed. I think it aligns more with how this SDK in other languages (I checked Go) behave.

How Has This Been Tested?

Currently, in Codex, adding Linear MCP server in a node:22-bookworm-slim container without ca-certificates installed shows the Linear MCP server as being unavailable even though the root cause is missing CA certificates on the system. With this change, the error is now clearer (even though Codex needs some change too in order to surface it properly).

Breaking Changes

N/A

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

DaleSeo · 2026-07-23T00:28:38Z

+ let response = self
+ .discovery_get(discovery_url)
+ .await
+ .map_err(|error| Self::discovery_failed(discovery_url, error))?;


Previously, if one candidate failed, the code moved on to the next well-known URL. Now it returns Err, and the existing ? in try_discover_oauth_server's candidate loop propagates the error and skips all remaining candidates. Is this intended?

Yeah, I think so. What's happening is that now we immediately bubble up errors during the request itself or if the response returns a 5xx (the latter is converted to an error in the new discovery_request method). The other status codes still return the same response and fall into the next checks for whether that response is a 200, 403, or 404.
I feel this is a good compromise, where if requesting one of the candidates returns an unexpected error, we still surface that to the user, but something like 200, 403, or 404 we know how to handle.

Makes sense. Thanks for the clarification.

DaleSeo · 2026-07-28T14:21:22Z

Hi @tjni, I'm sorry it took me so long to get back to your PR.
We're preparing the v3 release today and have very little time left to land this, so I opened #1069 to carry the work forward. I preserved your original commit and authorship as the first commit, then added a follow-up commit that revises the public error API while we can still make breaking changes.

tjni · 2026-07-28T16:43:49Z

Thank you so much for taking care of the all the details involved here.

tjni · 2026-07-22T21:05:42Z

Motivation and Context

OAuth discovery currently treats network and server failures as missing metadata, which can incorrectly make a server appear not to support OAuth even when the root cause could be a client-side issue or a server-side server error.

This change propagates such errors to clients so that they can be displayed. I think it aligns more with how this SDK in other languages (I checked Go) behave.

How Has This Been Tested?

Currently, in Codex, adding Linear MCP server in a node:22-bookworm-slim container without ca-certificates installed shows the Linear MCP server as being unavailable even though the root cause is missing CA certificates on the system. With this change, the error is now clearer (even though Codex needs some change too in order to surface it properly).

Breaking Changes

N/A

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

DaleSeo · 2026-07-23T00:28:38Z

+ let response = self
+ .discovery_get(discovery_url)
+ .await
+ .map_err(|error| Self::discovery_failed(discovery_url, error))?;


Previously, if one candidate failed, the code moved on to the next well-known URL. Now it returns Err, and the existing ? in try_discover_oauth_server's candidate loop propagates the error and skips all remaining candidates. Is this intended?

Yeah, I think so. What's happening is that now we immediately bubble up errors during the request itself or if the response returns a 5xx (the latter is converted to an error in the new discovery_request method). The other status codes still return the same response and fall into the next checks for whether that response is a 200, 403, or 404.
I feel this is a good compromise, where if requesting one of the candidates returns an unexpected error, we still surface that to the user, but something like 200, 403, or 404 we know how to handle.

Makes sense. Thanks for the clarification.

DaleSeo · 2026-07-28T14:21:22Z

Hi @tjni, I'm sorry it took me so long to get back to your PR.
We're preparing the v3 release today and have very little time left to land this, so I opened #1069 to carry the work forward. I preserved your original commit and authorship as the first commit, then added a follow-up commit that revises the public error API while we can still make breaking changes.

tjni · 2026-07-28T16:43:49Z

Thank you so much for taking care of the all the details involved here.

tjni · 2026-07-22T21:05:42Z

Motivation and Context

OAuth discovery currently treats network and server failures as missing metadata, which can incorrectly make a server appear not to support OAuth even when the root cause could be a client-side issue or a server-side server error.

This change propagates such errors to clients so that they can be displayed. I think it aligns more with how this SDK in other languages (I checked Go) behave.

How Has This Been Tested?

Currently, in Codex, adding Linear MCP server in a node:22-bookworm-slim container without ca-certificates installed shows the Linear MCP server as being unavailable even though the root cause is missing CA certificates on the system. With this change, the error is now clearer (even though Codex needs some change too in order to surface it properly).

Breaking Changes

N/A

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

DaleSeo · 2026-07-23T00:28:38Z

+ let response = self
+ .discovery_get(discovery_url)
+ .await
+ .map_err(|error| Self::discovery_failed(discovery_url, error))?;


Previously, if one candidate failed, the code moved on to the next well-known URL. Now it returns Err, and the existing ? in try_discover_oauth_server's candidate loop propagates the error and skips all remaining candidates. Is this intended?

Yeah, I think so. What's happening is that now we immediately bubble up errors during the request itself or if the response returns a 5xx (the latter is converted to an error in the new discovery_request method). The other status codes still return the same response and fall into the next checks for whether that response is a 200, 403, or 404.
I feel this is a good compromise, where if requesting one of the candidates returns an unexpected error, we still surface that to the user, but something like 200, 403, or 404 we know how to handle.

Makes sense. Thanks for the clarification.

DaleSeo · 2026-07-28T14:21:22Z

Hi @tjni, I'm sorry it took me so long to get back to your PR.
We're preparing the v3 release today and have very little time left to land this, so I opened #1069 to carry the work forward. I preserved your original commit and authorship as the first commit, then added a follow-up commit that revises the public error API while we can still make breaking changes.

tjni · 2026-07-28T16:43:49Z

Thank you so much for taking care of the all the details involved here.

tjni · 2026-07-22T21:05:42Z

Motivation and Context

OAuth discovery currently treats network and server failures as missing metadata, which can incorrectly make a server appear not to support OAuth even when the root cause could be a client-side issue or a server-side server error.

This change propagates such errors to clients so that they can be displayed. I think it aligns more with how this SDK in other languages (I checked Go) behave.

How Has This Been Tested?

Currently, in Codex, adding Linear MCP server in a node:22-bookworm-slim container without ca-certificates installed shows the Linear MCP server as being unavailable even though the root cause is missing CA certificates on the system. With this change, the error is now clearer (even though Codex needs some change too in order to surface it properly).

Breaking Changes

N/A

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

DaleSeo · 2026-07-23T00:28:38Z

+ let response = self
+ .discovery_get(discovery_url)
+ .await
+ .map_err(|error| Self::discovery_failed(discovery_url, error))?;


Previously, if one candidate failed, the code moved on to the next well-known URL. Now it returns Err, and the existing ? in try_discover_oauth_server's candidate loop propagates the error and skips all remaining candidates. Is this intended?

Yeah, I think so. What's happening is that now we immediately bubble up errors during the request itself or if the response returns a 5xx (the latter is converted to an error in the new discovery_request method). The other status codes still return the same response and fall into the next checks for whether that response is a 200, 403, or 404.
I feel this is a good compromise, where if requesting one of the candidates returns an unexpected error, we still surface that to the user, but something like 200, 403, or 404 we know how to handle.

Makes sense. Thanks for the clarification.

DaleSeo · 2026-07-28T14:21:22Z

Hi @tjni, I'm sorry it took me so long to get back to your PR.
We're preparing the v3 release today and have very little time left to land this, so I opened #1069 to carry the work forward. I preserved your original commit and authorship as the first commit, then added a follow-up commit that revises the public error API while we can still make breaking changes.

tjni · 2026-07-28T16:43:49Z

Thank you so much for taking care of the all the details involved here.

tjni · 2026-07-22T21:05:42Z

Motivation and Context

OAuth discovery currently treats network and server failures as missing metadata, which can incorrectly make a server appear not to support OAuth even when the root cause could be a client-side issue or a server-side server error.

This change propagates such errors to clients so that they can be displayed. I think it aligns more with how this SDK in other languages (I checked Go) behave.

How Has This Been Tested?

Currently, in Codex, adding Linear MCP server in a node:22-bookworm-slim container without ca-certificates installed shows the Linear MCP server as being unavailable even though the root cause is missing CA certificates on the system. With this change, the error is now clearer (even though Codex needs some change too in order to surface it properly).

Breaking Changes

N/A

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

DaleSeo · 2026-07-23T00:28:38Z

+ let response = self
+ .discovery_get(discovery_url)
+ .await
+ .map_err(|error| Self::discovery_failed(discovery_url, error))?;


Previously, if one candidate failed, the code moved on to the next well-known URL. Now it returns Err, and the existing ? in try_discover_oauth_server's candidate loop propagates the error and skips all remaining candidates. Is this intended?

Yeah, I think so. What's happening is that now we immediately bubble up errors during the request itself or if the response returns a 5xx (the latter is converted to an error in the new discovery_request method). The other status codes still return the same response and fall into the next checks for whether that response is a 200, 403, or 404.
I feel this is a good compromise, where if requesting one of the candidates returns an unexpected error, we still surface that to the user, but something like 200, 403, or 404 we know how to handle.

Makes sense. Thanks for the clarification.

DaleSeo · 2026-07-28T14:21:22Z

Hi @tjni, I'm sorry it took me so long to get back to your PR.
We're preparing the v3 release today and have very little time left to land this, so I opened #1069 to carry the work forward. I preserved your original commit and authorship as the first commit, then added a follow-up commit that revises the public error API while we can still make breaking changes.

tjni · 2026-07-28T16:43:49Z

Thank you so much for taking care of the all the details involved here.

tjni · 2026-07-22T21:05:42Z

Motivation and Context

OAuth discovery currently treats network and server failures as missing metadata, which can incorrectly make a server appear not to support OAuth even when the root cause could be a client-side issue or a server-side server error.

This change propagates such errors to clients so that they can be displayed. I think it aligns more with how this SDK in other languages (I checked Go) behave.

How Has This Been Tested?

Currently, in Codex, adding Linear MCP server in a node:22-bookworm-slim container without ca-certificates installed shows the Linear MCP server as being unavailable even though the root cause is missing CA certificates on the system. With this change, the error is now clearer (even though Codex needs some change too in order to surface it properly).

Breaking Changes

N/A

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

DaleSeo · 2026-07-23T00:28:38Z

+ let response = self
+ .discovery_get(discovery_url)
+ .await
+ .map_err(|error| Self::discovery_failed(discovery_url, error))?;


Previously, if one candidate failed, the code moved on to the next well-known URL. Now it returns Err, and the existing ? in try_discover_oauth_server's candidate loop propagates the error and skips all remaining candidates. Is this intended?

Yeah, I think so. What's happening is that now we immediately bubble up errors during the request itself or if the response returns a 5xx (the latter is converted to an error in the new discovery_request method). The other status codes still return the same response and fall into the next checks for whether that response is a 200, 403, or 404.
I feel this is a good compromise, where if requesting one of the candidates returns an unexpected error, we still surface that to the user, but something like 200, 403, or 404 we know how to handle.

Makes sense. Thanks for the clarification.

DaleSeo · 2026-07-28T14:21:22Z

Hi @tjni, I'm sorry it took me so long to get back to your PR.
We're preparing the v3 release today and have very little time left to land this, so I opened #1069 to carry the work forward. I preserved your original commit and authorship as the first commit, then added a follow-up commit that revises the public error API while we can still make breaking changes.

tjni · 2026-07-28T16:43:49Z

Thank you so much for taking care of the all the details involved here.

tjni · 2026-07-22T21:05:42Z

Motivation and Context

OAuth discovery currently treats network and server failures as missing metadata, which can incorrectly make a server appear not to support OAuth even when the root cause could be a client-side issue or a server-side server error.

This change propagates such errors to clients so that they can be displayed. I think it aligns more with how this SDK in other languages (I checked Go) behave.

How Has This Been Tested?

Currently, in Codex, adding Linear MCP server in a node:22-bookworm-slim container without ca-certificates installed shows the Linear MCP server as being unavailable even though the root cause is missing CA certificates on the system. With this change, the error is now clearer (even though Codex needs some change too in order to surface it properly).

Breaking Changes

N/A

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

DaleSeo · 2026-07-23T00:28:38Z

+ let response = self
+ .discovery_get(discovery_url)
+ .await
+ .map_err(|error| Self::discovery_failed(discovery_url, error))?;


Previously, if one candidate failed, the code moved on to the next well-known URL. Now it returns Err, and the existing ? in try_discover_oauth_server's candidate loop propagates the error and skips all remaining candidates. Is this intended?

Yeah, I think so. What's happening is that now we immediately bubble up errors during the request itself or if the response returns a 5xx (the latter is converted to an error in the new discovery_request method). The other status codes still return the same response and fall into the next checks for whether that response is a 200, 403, or 404.
I feel this is a good compromise, where if requesting one of the candidates returns an unexpected error, we still surface that to the user, but something like 200, 403, or 404 we know how to handle.

Makes sense. Thanks for the clarification.

DaleSeo · 2026-07-28T14:21:22Z

Hi @tjni, I'm sorry it took me so long to get back to your PR.
We're preparing the v3 release today and have very little time left to land this, so I opened #1069 to carry the work forward. I preserved your original commit and authorship as the first commit, then added a follow-up commit that revises the public error API while we can still make breaking changes.

tjni · 2026-07-28T16:43:49Z

Thank you so much for taking care of the all the details involved here.

tjni · 2026-07-22T21:05:42Z

Motivation and Context

OAuth discovery currently treats network and server failures as missing metadata, which can incorrectly make a server appear not to support OAuth even when the root cause could be a client-side issue or a server-side server error.

This change propagates such errors to clients so that they can be displayed. I think it aligns more with how this SDK in other languages (I checked Go) behave.

How Has This Been Tested?

Currently, in Codex, adding Linear MCP server in a node:22-bookworm-slim container without ca-certificates installed shows the Linear MCP server as being unavailable even though the root cause is missing CA certificates on the system. With this change, the error is now clearer (even though Codex needs some change too in order to surface it properly).

Breaking Changes

N/A

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

DaleSeo · 2026-07-23T00:28:38Z

+ let response = self
+ .discovery_get(discovery_url)
+ .await
+ .map_err(|error| Self::discovery_failed(discovery_url, error))?;


Previously, if one candidate failed, the code moved on to the next well-known URL. Now it returns Err, and the existing ? in try_discover_oauth_server's candidate loop propagates the error and skips all remaining candidates. Is this intended?

Yeah, I think so. What's happening is that now we immediately bubble up errors during the request itself or if the response returns a 5xx (the latter is converted to an error in the new discovery_request method). The other status codes still return the same response and fall into the next checks for whether that response is a 200, 403, or 404.
I feel this is a good compromise, where if requesting one of the candidates returns an unexpected error, we still surface that to the user, but something like 200, 403, or 404 we know how to handle.

Makes sense. Thanks for the clarification.

DaleSeo · 2026-07-28T14:21:22Z

Hi @tjni, I'm sorry it took me so long to get back to your PR.
We're preparing the v3 release today and have very little time left to land this, so I opened #1069 to carry the work forward. I preserved your original commit and authorship as the first commit, then added a follow-up commit that revises the public error API while we can still make breaking changes.

tjni · 2026-07-28T16:43:49Z

Thank you so much for taking care of the all the details involved here.

fix(auth): preserve OAuth discovery transport errors
f2e5f39

tjni requested a review from a team as a code owner July 22, 2026 21:05

github-actionsBot added T-core Core library changes T-transport Transport layer changes labels Jul 22, 2026

DaleSeo reviewed Jul 23, 2026
View reviewed changes

DaleSeo closed this Jul 28, 2026

DaleSeo mentioned this pull request Jul 28, 2026
fix!: preserve OAuth discovery transport errors #1069
Merged
9 tasks

tjni deleted the agent/preserve-oauth-discovery-errors branch July 28, 2026 16:43

fix(auth): preserve OAuth discovery transport errors
f2e5f39

tjni requested a review from a team as a code owner July 22, 2026 21:05

github-actionsBot added T-core Core library changes T-transport Transport layer changes labels Jul 22, 2026

DaleSeo reviewed Jul 23, 2026
View reviewed changes

DaleSeo closed this Jul 28, 2026

DaleSeo mentioned this pull request Jul 28, 2026
fix!: preserve OAuth discovery transport errors #1069
Merged
9 tasks

tjni deleted the agent/preserve-oauth-discovery-errors branch July 28, 2026 16:43

fix(auth): preserve OAuth discovery transport errors
f2e5f39

tjni requested a review from a team as a code owner July 22, 2026 21:05

github-actionsBot added T-core Core library changes T-transport Transport layer changes labels Jul 22, 2026

DaleSeo reviewed Jul 23, 2026
View reviewed changes

DaleSeo closed this Jul 28, 2026

DaleSeo mentioned this pull request Jul 28, 2026
fix!: preserve OAuth discovery transport errors #1069
Merged
9 tasks

tjni deleted the agent/preserve-oauth-discovery-errors branch July 28, 2026 16:43

fix(auth): preserve OAuth discovery transport errors
f2e5f39

tjni requested a review from a team as a code owner July 22, 2026 21:05

github-actionsBot added T-core Core library changes T-transport Transport layer changes labels Jul 22, 2026

DaleSeo reviewed Jul 23, 2026
View reviewed changes

DaleSeo closed this Jul 28, 2026

DaleSeo mentioned this pull request Jul 28, 2026
fix!: preserve OAuth discovery transport errors #1069
Merged
9 tasks

tjni deleted the agent/preserve-oauth-discovery-errors branch July 28, 2026 16:43

fix(auth): preserve OAuth discovery transport errors
f2e5f39

tjni requested a review from a team as a code owner July 22, 2026 21:05

github-actionsBot added T-core Core library changes T-transport Transport layer changes labels Jul 22, 2026

DaleSeo reviewed Jul 23, 2026
View reviewed changes

DaleSeo closed this Jul 28, 2026

DaleSeo mentioned this pull request Jul 28, 2026
fix!: preserve OAuth discovery transport errors #1069
Merged
9 tasks

tjni deleted the agent/preserve-oauth-discovery-errors branch July 28, 2026 16:43

fix(auth): preserve OAuth discovery transport errors
f2e5f39

tjni requested a review from a team as a code owner July 22, 2026 21:05

github-actionsBot added T-core Core library changes T-transport Transport layer changes labels Jul 22, 2026

DaleSeo reviewed Jul 23, 2026
View reviewed changes

DaleSeo closed this Jul 28, 2026

DaleSeo mentioned this pull request Jul 28, 2026
fix!: preserve OAuth discovery transport errors #1069
Merged
9 tasks

tjni deleted the agent/preserve-oauth-discovery-errors branch July 28, 2026 16:43

fix(auth): preserve OAuth discovery transport errors
f2e5f39

tjni requested a review from a team as a code owner July 22, 2026 21:05

github-actionsBot added T-core Core library changes T-transport Transport layer changes labels Jul 22, 2026

DaleSeo reviewed Jul 23, 2026
View reviewed changes

DaleSeo closed this Jul 28, 2026

DaleSeo mentioned this pull request Jul 28, 2026
fix!: preserve OAuth discovery transport errors #1069
Merged
9 tasks

tjni deleted the agent/preserve-oauth-discovery-errors branch July 28, 2026 16:43

fix(auth): preserve OAuth discovery transport errors
f2e5f39

tjni requested a review from a team as a code owner July 22, 2026 21:05

github-actionsBot added T-core Core library changes T-transport Transport layer changes labels Jul 22, 2026

DaleSeo reviewed Jul 23, 2026
View reviewed changes

DaleSeo closed this Jul 28, 2026

DaleSeo mentioned this pull request Jul 28, 2026
fix!: preserve OAuth discovery transport errors #1069
Merged
9 tasks

tjni deleted the agent/preserve-oauth-discovery-errors branch July 28, 2026 16:43

Uh oh!

Conversation

tjni commented Jul 22, 2026

Motivation and Context

How Has This Been Tested?

Breaking Changes

Types of changes

Checklist

Additional context

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DaleSeo commented Jul 28, 2026

Uh oh!

tjni commented Jul 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

tjni commented Jul 22, 2026

Motivation and Context

How Has This Been Tested?

Breaking Changes

Types of changes

Checklist

Additional context

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DaleSeo commented Jul 28, 2026

Uh oh!

tjni commented Jul 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

tjni commented Jul 22, 2026

Motivation and Context

How Has This Been Tested?

Breaking Changes

Types of changes

Checklist

Additional context

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DaleSeo commented Jul 28, 2026

Uh oh!

tjni commented Jul 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects