Connexion3 Failed to load API definition in the Swagger UI

[vladislavkoz]

Description

It works perfectly fine locally and it works fine during some time after deployment. But after some time returns 500 error code. API itself works fine and all end-points works fine. The issue with Swagger UI only.
Before we added an exception handler we had just 500 error with the default message saying that something went wrong or app overloaded.
Now we use the following error_handler:

def connexion_base_exception_handler(
    request: ConnexionRequest, exc: Exception
) -> ConnexionResponse:
    return ConnexionResponse(
        status_code=500,
        body=json.dumps({"error": str(exc)}),
        content_type="application/json",
    )

As a result, str(exc) is actually openapi.json content

I've found the follwoing message in logs but we do not use "oneOf":
`Failed validating 'oneOf' in schema['properties']['paths']['patternProperties']['^\/']['patternProperties']['^(get|put|post|delete|options|head|patch|trace)$']['properties']['requestBody']:

`

Expected behaviour

API definition loaded correctly

Additional info:

Output of the commands:

• python --version python:3.10
• pip show connexion | grep "^Version\:". connexion[flask]==3.0.3
• starlette. 0.33.0 or 0.32.0.post1

openapi.yaml: openapi: 3.0.0

[nielsbox]

Have the same issue!

[Ruwann]

It first works and then stops working after some time? Do you know whether it's always approximately the same amount of time or just randomly?

@nielsbox
Do you also get the same error message with the oneOf? Are you using OpenAPI 3.0 as well or Swagger 2.0?

[nielsbox]

It's not exactly the same error message, but is related to the specification not being handled correctly since 3.0.3

InvalidSpecification: [{'name': 'body', 'in': 'body', 'schema': {'type': 'object', 'additionalProperties': False, 'properties': {'name': {'type': 'string', 'description': 'The name of the table'}, 'boost': {'type': 'number', 'description': 'The boost of the table'}, 'provider_id': {'type': 'string', 'description': 'The provider id of the table'}, 'lookup': {'type': 'boolean', 'description': 'Whether the table can be used within lookup'}}}}, {'name': 'inbox_id', 'in': 'path', 'required': True, 'type': 'string'}, {'name': 'inbox_id', 'in': 'path', 'required': True, 'type': 'string'}, {'name': 'inbox_id', 'in': 'path', 'required': True, 'type': 'string'}, {'name': 'inbox_id', 'in': 'path', 'required': True, 'type': 'string'}, {'name': 'inbox_id', 'in': 'path', 'required': True, 'type': 'string'}, {'name': 'inbox_id', 'in': 'path', 'required': True, 'type': 'string'}] has non-unique elements
  File "starlette/_exception_handler.py", line 44, in wrapped_app
    await app(scope, receive, sender)
  File "starlette/routing.py", line 70, in app
    response = await func(request)
  File "connexion/middleware/swagger_ui.py", line 108, in _get_openapi_json
    content=jsonifier.dumps(self._spec_for_prefix(request)),
  File "connexion/middleware/swagger_ui.py", line 71, in _spec_for_prefix
    return self.specification.with_base_path(base_path).raw
  File "connexion/spec.py", line 209, in with_base_path
    new_spec = self.clone()
  File "connexion/spec.py", line 199, in clone
    return type(self)(copy.deepcopy(self._spec))
  File "connexion/spec.py", line 82, in __init__
    self._validate_spec(raw_spec)
  File "connexion/spec.py", line 98, in _validate_spec
    raise InvalidSpecification.create_from(e)

Seems to be repeating some of my parameters. Tested 3.0.2 and 3.0.3 (and 3.0.4)
Only works on 3.0.2. Even with pinning the dependencies of 3.0.2. So the issue seems to be isolated to the change made in 3.0.3 to the routing.

[vladislavkoz]

Fixed in 3.0.5. Thanks

[RDWimmers]

I would like to request that this issue #1829 be reopened. While it was previously marked as resolved/closed, I believe the problem is occurring in the latest version 3.2.0 due to reverting the fix in commit bb48fb3.

@vladislavkoz / @RobbeSneyders do you agree?

Let me know if you need further clarification or additional information. Thank you for your time and consideration!

[vladislavkoz]

@RDWimmers I didn't try 3.2.0 so can't confirm this.

[wemcouncil]

I have run into the same issue, rolling back to 3.1.0 from 3.2.0 fixes the problem. If I have time, I will look into this tomorrow to see if I can find any clues. Issue 2029 relevant for me as well

[tuomastik]

I can also confirm the issue is back with 3.2.0 and 3.1.0 fixes the problem.