OAuth regression for runlayer backed servers

[technicalpickles]

I was helping someone set mcpproxy up, and they ran into these errors to oauth:

{
  "detail": [
    {
      "type": "missing",
      "loc": [
        "query",
        "resource"
      ],
      "msg": "Field required",
      "input": null
    }
  ]
}

This is a regression of #155

I had been running off the version on #255 and was able to reproduce once i merged main.

[technicalpickles]

Possibly related? #251 #262

[Dumbris]

Thanks for reporting this bug!

I was able to reproduce the error locally using a mock OAuth server built with FastMCP. The Pydantic validation error format matched exactly what you reported:

{"detail": [{"type": "missing", "loc": ["query", "resource"], "msg": "Field required", "input": null}]}

Root cause: The resource parameter (RFC 8707) was being auto-detected correctly, but it wasn't being injected into the authorization URL in the API/UI login flow. The CLI login flow worked because it had the injection code, but the newer API login functions added in Spec 020 were missing it.

Fix: PR #272 adds the missing extraParams injection to both affected functions and includes an E2E regression test with a mock Runlayer-style OAuth server.

[Dumbris]

The fix has been released in v0.15.5.

Could you try it and let us know if it resolves the issue?

[technicalpickles]

Awesome, thanks! I'll try today

I was able to reproduce the error locally using a mock OAuth server built with FastMCP. The Pydantic validation error format matched exactly what you reported:

Something I have been thinking is it would be worth having a handful of these to test against. That would make development a TON easier, and we could also do integration tests with them to catch regressions like this.

[technicalpickles]

I'm still seeing the problem. Will debug next week and let you know what I'm seeing.

[Dumbris]

I've been trying to reproduce this with our local mock servers (including a new Runlayer-style mock that returns the same Pydantic 422 errors #275 ), but so far our tests pass - the resource parameter is being injected correctly into the auth URL.

I'm wondering if the issue might not be the OAuth flow itself but something else:

• Cached old token - Could there be a stale token from before the fix? Try clearing it with:
  mcpproxy auth logout --server=
• Then re-authenticate with mcpproxy auth login --server=
• Different login method - Are you using CLI login (mcpproxy auth login), Web UI, or the REST API? There might be a code path difference we haven't covered

[Dumbris]

@technicalpickles checking in — OAuth has been heavily reworked since v0.15.5 (Spec 023 added persistent OAuth state with the oauth_tokens BBolt bucket, automatic refresh, and OAuth-token cleanup landed in #297).

Could you confirm whether this is still reproducing on v0.29.2 against a Runlayer-backed server? If yes, a fresh mcpproxy upstream logs <name> --tail 200 and the request_id from a failed auth attempt (X-Request-Id header → mcpproxy activity list --request-id <id>) would help a lot. If you can't repro any more, feel free to close.

Will close in ~2 weeks if there's no update.