Skip to content

[ENHANCEMENT] Report an MCP OAuth callback failure before retrying #2187

Open

Description

@SoccerField24x7

Problem (one or two sentences)

An MCP OAuth callback can fail before the authorization flow starts waiting for it. The next wait then starts a new callback listener and can hide the original error for up to five minutes.

Context (who is affected and when)

This affects users of remote MCP servers that use a static OAuth client without a configured redirect URI. It can happen when the callback listener times out or fails before the user starts or completes authentication.

Desired behavior (conceptual, not technical)

Report the pending callback failure when the authorization flow first waits for a result. After the application reports that failure, a later authorization attempt must be able to start a new callback listener.

Constraints / preferences (optional)

Keep the current protection against unhandled promise rejections. Always close a failed callback listener. Do not let cleanup replace the original callback error. Preserve support for a later authentication retry.

Request checklist

  • I searched the existing Issues and Discussions for duplicates
  • This describes a specific problem with clear context and impact

Zoo Code Task Links (optional)

Given an MCP OAuth callback listener that fails before waitForAuthCode is called
When waitForAuthCode is called for the first time
Then it reports the original callback error without starting another listener

Given the application has reported that callback error
When a later authorization attempt starts
Then it creates a new callback listener
And it can receive a new authorization result

Given a caller is already waiting when the callback fails
When the failure occurs
Then that caller receives the original callback error

Given a callback listener fails
When the provider cleans it up
Then the provider closes the failed listener
And no unhandled promise rejection occurs
And a cleanup error does not replace the original callback error

Acceptance criteria (optional)

No response

Proposed approach (optional)

Track a failed callback result separately from the active callback listener. Keep the failed result until waitForAuthCode reports it once. Clear the consumed failure before a later authorization attempt starts a new listener.

Add tests for both timing orders. Test a caller that waits before the failure. Test a callback that fails before the first caller waits.

This issue follows the review discussion in PR #2129:
#2129 (comment)

The original static OAuth feature was completed by #2096 and PR #2129.

Trade-offs / risks (optional)

Keeping a failed result adds callback lifecycle state. The implementation must prevent an old failure from affecting a replacement listener.

Returning the failure once can require the user to start authentication again. This is preferable to hiding the error behind a new five-minute wait.

Changing only the source comment would be simpler, but it would keep the weaker error-reporting behavior.

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

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions