fix: preserve transient OAuth discovery HTTP errors by tsarlandie-oai · Pull Request #1071 · modelcontextprotocol/rust-sdk

tsarlandie-oai · 2026-07-28T16:53:41Z

Summary

Follow-up to #1069.

OAuth metadata discovery now preserves transport failures and HTTP 5xx responses, but HTTP 408 Request Timeout, 425 Too Early, and 429 Too Many Requests still fall through as though a metadata endpoint were absent. As a result, a temporary timeout, early-data rejection, or rate limit can cause discovery to continue to another endpoint or report a legacy fallback instead of surfacing the operational failure.

This change classifies HTTP 408, 425, and 429 alongside 5xx in the existing discovery_request helper. The resulting metadata error preserves both the actual response status and the failing discovery URL.

Compatibility

Preserve HTTP 401 challenge handling.
Preserve HTTP 404 and 405 discovery fallback, with separate regression cases for both.
Preserve the existing HTTP 5xx behavior.
Do not introduce automatic retries, new dependencies, or public API changes.

Regression coverage

Add nine parameterized cases covering HTTP 408, 425, and 429 at each of:

The protected resource endpoint.
The protected resource metadata endpoint.
The authorization server metadata endpoint.

Each case verifies that discovery reports the correct failing URL and status and does not issue additional discovery requests. The regression was first reproduced against upstream main before applying the production fix.

Validation

cargo +1.96 test -p rmcp --lib --all-features (482 tests passing).
cargo +1.96 clippy --all-targets --all-features -- -D warnings.
cargo +nightly-2025-09-18 fmt --all -- --check.

DaleSeo

Thanks for tightening the discovery error boundary!

DaleSeo · 2026-07-28T17:37:55Z

+ if status.is_server_error()
+ || matches!(
+ status,
+ StatusCode::REQUEST_TIMEOUT | StatusCode::TOO_MANY_REQUESTS


Would 425 would make the transient classification more complete?

tsarlandie-oai · 2026-07-28T16:53:41Z

Summary

Follow-up to #1069.

OAuth metadata discovery now preserves transport failures and HTTP 5xx responses, but HTTP 408 Request Timeout, 425 Too Early, and 429 Too Many Requests still fall through as though a metadata endpoint were absent. As a result, a temporary timeout, early-data rejection, or rate limit can cause discovery to continue to another endpoint or report a legacy fallback instead of surfacing the operational failure.

This change classifies HTTP 408, 425, and 429 alongside 5xx in the existing discovery_request helper. The resulting metadata error preserves both the actual response status and the failing discovery URL.

Compatibility

Preserve HTTP 401 challenge handling.
Preserve HTTP 404 and 405 discovery fallback, with separate regression cases for both.
Preserve the existing HTTP 5xx behavior.
Do not introduce automatic retries, new dependencies, or public API changes.

Regression coverage

Add nine parameterized cases covering HTTP 408, 425, and 429 at each of:

The protected resource endpoint.
The protected resource metadata endpoint.
The authorization server metadata endpoint.

Each case verifies that discovery reports the correct failing URL and status and does not issue additional discovery requests. The regression was first reproduced against upstream main before applying the production fix.

Validation

cargo +1.96 test -p rmcp --lib --all-features (482 tests passing).
cargo +1.96 clippy --all-targets --all-features -- -D warnings.
cargo +nightly-2025-09-18 fmt --all -- --check.

DaleSeo

Thanks for tightening the discovery error boundary!

DaleSeo · 2026-07-28T17:37:55Z

+ if status.is_server_error()
+ || matches!(
+ status,
+ StatusCode::REQUEST_TIMEOUT | StatusCode::TOO_MANY_REQUESTS


Would 425 would make the transient classification more complete?

tsarlandie-oai · 2026-07-28T16:53:41Z

Summary

Follow-up to #1069.

OAuth metadata discovery now preserves transport failures and HTTP 5xx responses, but HTTP 408 Request Timeout, 425 Too Early, and 429 Too Many Requests still fall through as though a metadata endpoint were absent. As a result, a temporary timeout, early-data rejection, or rate limit can cause discovery to continue to another endpoint or report a legacy fallback instead of surfacing the operational failure.

This change classifies HTTP 408, 425, and 429 alongside 5xx in the existing discovery_request helper. The resulting metadata error preserves both the actual response status and the failing discovery URL.

Compatibility

Preserve HTTP 401 challenge handling.
Preserve HTTP 404 and 405 discovery fallback, with separate regression cases for both.
Preserve the existing HTTP 5xx behavior.
Do not introduce automatic retries, new dependencies, or public API changes.

Regression coverage

Add nine parameterized cases covering HTTP 408, 425, and 429 at each of:

The protected resource endpoint.
The protected resource metadata endpoint.
The authorization server metadata endpoint.

Each case verifies that discovery reports the correct failing URL and status and does not issue additional discovery requests. The regression was first reproduced against upstream main before applying the production fix.

Validation

cargo +1.96 test -p rmcp --lib --all-features (482 tests passing).
cargo +1.96 clippy --all-targets --all-features -- -D warnings.
cargo +nightly-2025-09-18 fmt --all -- --check.

DaleSeo

Thanks for tightening the discovery error boundary!

DaleSeo · 2026-07-28T17:37:55Z

+ if status.is_server_error()
+ || matches!(
+ status,
+ StatusCode::REQUEST_TIMEOUT | StatusCode::TOO_MANY_REQUESTS


Would 425 would make the transient classification more complete?

tsarlandie-oai · 2026-07-28T16:53:41Z

Summary

Follow-up to #1069.

OAuth metadata discovery now preserves transport failures and HTTP 5xx responses, but HTTP 408 Request Timeout, 425 Too Early, and 429 Too Many Requests still fall through as though a metadata endpoint were absent. As a result, a temporary timeout, early-data rejection, or rate limit can cause discovery to continue to another endpoint or report a legacy fallback instead of surfacing the operational failure.

This change classifies HTTP 408, 425, and 429 alongside 5xx in the existing discovery_request helper. The resulting metadata error preserves both the actual response status and the failing discovery URL.

Compatibility

Preserve HTTP 401 challenge handling.
Preserve HTTP 404 and 405 discovery fallback, with separate regression cases for both.
Preserve the existing HTTP 5xx behavior.
Do not introduce automatic retries, new dependencies, or public API changes.

Regression coverage

Add nine parameterized cases covering HTTP 408, 425, and 429 at each of:

The protected resource endpoint.
The protected resource metadata endpoint.
The authorization server metadata endpoint.

Each case verifies that discovery reports the correct failing URL and status and does not issue additional discovery requests. The regression was first reproduced against upstream main before applying the production fix.

Validation

cargo +1.96 test -p rmcp --lib --all-features (482 tests passing).
cargo +1.96 clippy --all-targets --all-features -- -D warnings.
cargo +nightly-2025-09-18 fmt --all -- --check.

DaleSeo

Thanks for tightening the discovery error boundary!

DaleSeo · 2026-07-28T17:37:55Z

+ if status.is_server_error()
+ || matches!(
+ status,
+ StatusCode::REQUEST_TIMEOUT | StatusCode::TOO_MANY_REQUESTS


Would 425 would make the transient classification more complete?

tsarlandie-oai · 2026-07-28T16:53:41Z

Summary

Follow-up to #1069.

OAuth metadata discovery now preserves transport failures and HTTP 5xx responses, but HTTP 408 Request Timeout, 425 Too Early, and 429 Too Many Requests still fall through as though a metadata endpoint were absent. As a result, a temporary timeout, early-data rejection, or rate limit can cause discovery to continue to another endpoint or report a legacy fallback instead of surfacing the operational failure.

This change classifies HTTP 408, 425, and 429 alongside 5xx in the existing discovery_request helper. The resulting metadata error preserves both the actual response status and the failing discovery URL.

Compatibility

Preserve HTTP 401 challenge handling.
Preserve HTTP 404 and 405 discovery fallback, with separate regression cases for both.
Preserve the existing HTTP 5xx behavior.
Do not introduce automatic retries, new dependencies, or public API changes.

Regression coverage

Add nine parameterized cases covering HTTP 408, 425, and 429 at each of:

The protected resource endpoint.
The protected resource metadata endpoint.
The authorization server metadata endpoint.

Each case verifies that discovery reports the correct failing URL and status and does not issue additional discovery requests. The regression was first reproduced against upstream main before applying the production fix.

Validation

cargo +1.96 test -p rmcp --lib --all-features (482 tests passing).
cargo +1.96 clippy --all-targets --all-features -- -D warnings.
cargo +nightly-2025-09-18 fmt --all -- --check.

DaleSeo

Thanks for tightening the discovery error boundary!

DaleSeo · 2026-07-28T17:37:55Z

+ if status.is_server_error()
+ || matches!(
+ status,
+ StatusCode::REQUEST_TIMEOUT | StatusCode::TOO_MANY_REQUESTS


Would 425 would make the transient classification more complete?

tsarlandie-oai · 2026-07-28T16:53:41Z

Summary

Follow-up to #1069.

OAuth metadata discovery now preserves transport failures and HTTP 5xx responses, but HTTP 408 Request Timeout, 425 Too Early, and 429 Too Many Requests still fall through as though a metadata endpoint were absent. As a result, a temporary timeout, early-data rejection, or rate limit can cause discovery to continue to another endpoint or report a legacy fallback instead of surfacing the operational failure.

This change classifies HTTP 408, 425, and 429 alongside 5xx in the existing discovery_request helper. The resulting metadata error preserves both the actual response status and the failing discovery URL.

Compatibility

Preserve HTTP 401 challenge handling.
Preserve HTTP 404 and 405 discovery fallback, with separate regression cases for both.
Preserve the existing HTTP 5xx behavior.
Do not introduce automatic retries, new dependencies, or public API changes.

Regression coverage

Add nine parameterized cases covering HTTP 408, 425, and 429 at each of:

The protected resource endpoint.
The protected resource metadata endpoint.
The authorization server metadata endpoint.

Each case verifies that discovery reports the correct failing URL and status and does not issue additional discovery requests. The regression was first reproduced against upstream main before applying the production fix.

Validation

cargo +1.96 test -p rmcp --lib --all-features (482 tests passing).
cargo +1.96 clippy --all-targets --all-features -- -D warnings.
cargo +nightly-2025-09-18 fmt --all -- --check.

DaleSeo

Thanks for tightening the discovery error boundary!

DaleSeo · 2026-07-28T17:37:55Z

+ if status.is_server_error()
+ || matches!(
+ status,
+ StatusCode::REQUEST_TIMEOUT | StatusCode::TOO_MANY_REQUESTS


Would 425 would make the transient classification more complete?

tsarlandie-oai · 2026-07-28T16:53:41Z

Summary

Follow-up to #1069.

OAuth metadata discovery now preserves transport failures and HTTP 5xx responses, but HTTP 408 Request Timeout, 425 Too Early, and 429 Too Many Requests still fall through as though a metadata endpoint were absent. As a result, a temporary timeout, early-data rejection, or rate limit can cause discovery to continue to another endpoint or report a legacy fallback instead of surfacing the operational failure.

This change classifies HTTP 408, 425, and 429 alongside 5xx in the existing discovery_request helper. The resulting metadata error preserves both the actual response status and the failing discovery URL.

Compatibility

Preserve HTTP 401 challenge handling.
Preserve HTTP 404 and 405 discovery fallback, with separate regression cases for both.
Preserve the existing HTTP 5xx behavior.
Do not introduce automatic retries, new dependencies, or public API changes.

Regression coverage

Add nine parameterized cases covering HTTP 408, 425, and 429 at each of:

The protected resource endpoint.
The protected resource metadata endpoint.
The authorization server metadata endpoint.

Each case verifies that discovery reports the correct failing URL and status and does not issue additional discovery requests. The regression was first reproduced against upstream main before applying the production fix.

Validation

cargo +1.96 test -p rmcp --lib --all-features (482 tests passing).
cargo +1.96 clippy --all-targets --all-features -- -D warnings.
cargo +nightly-2025-09-18 fmt --all -- --check.

DaleSeo

Thanks for tightening the discovery error boundary!

DaleSeo · 2026-07-28T17:37:55Z

+ if status.is_server_error()
+ || matches!(
+ status,
+ StatusCode::REQUEST_TIMEOUT | StatusCode::TOO_MANY_REQUESTS


Would 425 would make the transient classification more complete?

tsarlandie-oai · 2026-07-28T16:53:41Z

Summary

Follow-up to #1069.

OAuth metadata discovery now preserves transport failures and HTTP 5xx responses, but HTTP 408 Request Timeout, 425 Too Early, and 429 Too Many Requests still fall through as though a metadata endpoint were absent. As a result, a temporary timeout, early-data rejection, or rate limit can cause discovery to continue to another endpoint or report a legacy fallback instead of surfacing the operational failure.

This change classifies HTTP 408, 425, and 429 alongside 5xx in the existing discovery_request helper. The resulting metadata error preserves both the actual response status and the failing discovery URL.

Compatibility

Preserve HTTP 401 challenge handling.
Preserve HTTP 404 and 405 discovery fallback, with separate regression cases for both.
Preserve the existing HTTP 5xx behavior.
Do not introduce automatic retries, new dependencies, or public API changes.

Regression coverage

Add nine parameterized cases covering HTTP 408, 425, and 429 at each of:

The protected resource endpoint.
The protected resource metadata endpoint.
The authorization server metadata endpoint.

Each case verifies that discovery reports the correct failing URL and status and does not issue additional discovery requests. The regression was first reproduced against upstream main before applying the production fix.

Validation

cargo +1.96 test -p rmcp --lib --all-features (482 tests passing).
cargo +1.96 clippy --all-targets --all-features -- -D warnings.
cargo +nightly-2025-09-18 fmt --all -- --check.

DaleSeo

Thanks for tightening the discovery error boundary!

DaleSeo · 2026-07-28T17:37:55Z

+ if status.is_server_error()
+ || matches!(
+ status,
+ StatusCode::REQUEST_TIMEOUT | StatusCode::TOO_MANY_REQUESTS


Would 425 would make the transient classification more complete?

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

tsarlandie-oai mentioned this pull request Jul 28, 2026
fix(auth): propagate retryable OAuth discovery errors #1072
Closed

tsarlandie-oai marked this pull request as ready for review July 28, 2026 16:58

tsarlandie-oai requested a review from a team as a code owner July 28, 2026 16:58

DaleSeo previously approved these changes Jul 28, 2026
View reviewed changes

tsarlandie-oai dismissed DaleSeo’s stale review via 7d80f6dJuly 28, 2026 18:16

tsarlandie-oai added 2 commits July 28, 2026 18:52

fix: preserve transient OAuth discovery HTTP errors
3ebd3e2

fix: preserve HTTP 425 during OAuth discovery
bf9e7c5

tsarlandie-oai force-pushed the codex/oauth-discovery-transient-http-errors branch from 7d80f6d to bf9e7c5Compare July 28, 2026 18:53

DaleSeo approved these changes Jul 28, 2026
View reviewed changes

DaleSeo merged commit 82a6c48 into modelcontextprotocol:mainJul 28, 2026
22 checks passed

This was referenced Jul 28, 2026
chore: release v3.0.0-beta.5 #1070
Merged
MCP upstream changes need Soma review dinglebear-ai/soma#78
Open