Polymorphic serializer not working as expected for 400 Bad Request

[mdefeche]

Hello,

First of all, thank you for the new release, it's very neat. I could totally get rid of my own custom AutoSchema =)

I noticed that the polymorphic serializer used for the 400 Bad Request is not rendered as expected on Redoc as shown below. I would expect to have validation_error and parse_error shown in the dropdown but it only shows null

While reading the code, I also noticed that the ParseErrorReponseSerializer is using the ClientErrorEnum class. Shouldn't it be the ParseErrorCodeEnum class instead ?

class ParseErrorResponseSerializer(serializers.Serializer):
    type = serializers.ChoiceField(choices=ClientErrorEnum.choices)
    errors = ParseErrorSerializer(many=True)

Thanks again for the hard work !

[ghazi-git]

You're welcome and thanks for taking the time to report the issues you find.

About the parse errors, that's actually correct, the type should be client_error while the code is parse_error (this page talks more about error types). So, a parse error response should look like

{
    "type": "client_error",
    "errors": [
        {
            "code": "parse_error",
            "detail": "Malformed request.",
            "attr": null
        }
    ]
}

To be honest, I use swagger UI. I assumed if it worked on swagger UI then it should work on redoc. But, I was wrong 🤦‍♂️

Everything looks good on swagger UI (a "post /login" operation):

But with redoc, I see the same issue as you (that weird null value as the first option whenever a polymorphic serializer is used)

I'll try to look more into it in the coming days and report back what I find out.

[mdefeche]

I'm using drf-spectacular PolymorphicSerializer in my projects and it's displayed correctly with Redoc

Here is the corresponding OpenAPI element

Question:
      oneOf:
      - $ref: '#/components/schemas/QuestionOption'
      - $ref: '#/components/schemas/QuestionOption'
      - $ref: '#/components/schemas/QuestionOption'
      - $ref: '#/components/schemas/QuestionTable'
      - $ref: '#/components/schemas/QuestionNothing'
      - $ref: '#/components/schemas/QuestionNothing'
      - $ref: '#/components/schemas/QuestionInfo'
      - $ref: '#/components/schemas/QuestionNothing'
      discriminator:
        propertyName: type
        mapping:
          CHOICE: '#/components/schemas/QuestionOption'
          MULTIPLE_CHOICES: '#/components/schemas/QuestionOption'
          ORDER: '#/components/schemas/QuestionOption'
          TABLE: '#/components/schemas/QuestionTable'
          INPUT: '#/components/schemas/QuestionNothing'
          DATE: '#/components/schemas/QuestionNothing'
          INFO: '#/components/schemas/QuestionInfo'
          RANGE: '#/components/schemas/QuestionNothing'

But for the 400 error body I get only one mapping (would expect two) and the type value is null (I guess both elements of the oneOf have a mapping to null, so one might override the other)

    DataClientsAccountsUpdateErrorResponse400:
      oneOf:
      - $ref: '#/components/schemas/DataClientsAccountsUpdateValidationError'
      - $ref: '#/components/schemas/ParseErrorResponse'
      discriminator:
        propertyName: type
        mapping:
          null: '#/components/schemas/ParseErrorResponse'

It seems this behaviour happens in other places where oneOf is used

    DataPortfoliosCreateError:
      oneOf:
      - $ref: '#/components/schemas/DataPortfoliosCreateNonFieldErrorsErrorComponent'
      - $ref: '#/components/schemas/DataPortfoliosCreateNameErrorComponent'
      - $ref: '#/components/schemas/DataPortfoliosCreateCodeErrorComponent'
      - $ref: '#/components/schemas/DataPortfoliosCreateSavedErrorComponent'
      - $ref: '#/components/schemas/DataPortfoliosCreateAllocationIdsNonFieldErrorsErrorComponent'
      - $ref: '#/components/schemas/DataPortfoliosCreateAllocationIdsINDEXNonFieldErrorsErrorComponent'
      - $ref: '#/components/schemas/DataPortfoliosCreateAllocationIdsINDEXCodeErrorComponent'
      - $ref: '#/components/schemas/DataPortfoliosCreateAllocationIdsINDEXShareErrorComponent'
      discriminator:
        propertyName: attr
        mapping:
          null: '#/components/schemas/DataPortfoliosCreateAllocationIdsINDEXShareErrorComponent'

Thanks again

[ghazi-git]

The issue is fixed now (I just release a new version 0.12.1), the schema generated should no longer have null, rather the correct mapping, sth like this:

AuthLoginCreateErrorResponse400:
      oneOf:
      - $ref: '#/components/schemas/AuthLoginCreateValidationError'
      - $ref: '#/components/schemas/ParseErrorResponse'
      discriminator:
        propertyName: type
        mapping:
          validation_error: '#/components/schemas/AuthLoginCreateValidationError'
          client_error: '#/components/schemas/ParseErrorResponse'

The corresponding redoc page will show

Before, I read in polymorphic serializer docs that

It is strongly recommended to pass the Serializers as list, and by that let drf-spectacular retrieve the field and handle the mapping automatically. In special circumstances, the field may not available when drf-spectacular processes the serializer. In those cases you can explicitly state the mapping with {'legal': LegalPersonSerializer, ...}, but it is then your responsibility to have a valid mapping.

So, I didn't question passing a list of serializers when everything looked fine in swagger UI. But, it seems like this is one of the special cases.

Anyway, thanks again for reporting the issue and all the details about it 🙏