@p1c2u This answer was extremely helpful, thank you! I had posted some comments with additional questions, but I deleted them because they were based on a partial misunderstanding of how OpenAPI works. But I understand how server URLs work now and we were able to resolve the issues with our app. Thanks again for your quick response!

In case anyone reading this is having a similar issue, our problem was that we have an AWS CloudFront distribution that forwards API requests to our AWS ApiGateway app. The forwarded requests have a URL like <api-gateway-url>/api/<endpoint>, e.g. https://vd2gh6uqw3.execute-api.us-west-2.amazonaws.com/api/user, but our app does not expect the /api component. Fixing this issue is as simple as specifying the following relative server URLs in our OpenAPI spec:

servers:
  - url: /
  - url: /api

The / url is technically optional, but including it allows us to make queries via our Swagger UI (which would force us to send requests to /api if that were the only server url specified).

I'm glad you found the problem. Any suggestions about debugging improvements are welcome.

@p1c2u I think the error message for the ServerNotFound exception could be improved. When I first saw the error:

Server not found for https://vd2gh6uqw3.execute-api.us-west-2.amazonaws.com/api/user

I assumed that the request had failed to reach the server. I did not even realize that the error was coming from the OpenAPI spec validator. At a minimum, I think the error message should make it clear that this is an OpenAPI spec validation problem. For example, it could say something like this:

Request is not valid for the given OpenAPI spec: Request URL https://vd2gh6uqw3.execute-api.us-west-2.amazonaws.com/api/user does not match any of the OpenAPI spec server URLs

In fact, I think that all request validation errors should begin with something like Request is not valid for the given OpenAPI spec: to make it clear that this is an OpenAPI spec error.