a problem with creating a schema with drf 3.10.3

[fannyhub]

Describe the bug
I have used drf version 3.10.3 as suggested and my previous problem has been resolved.
Alas, the schema still does not get built, failing with:
AssertionError: Incompatible AutoSchema used on View <class 'view-name'>. Is DRF's DEFAULT_SCHEMA_CLASS pointing to "drf_spectacular.openapi.AutoSchema" or any other drf-spectacular compatible AutoSchema?

This happens although I have set DEFAULT_SCHEMA_CLASS in REST_FRAMEWORK settings to drf_spectacular.openapi.AutoSchema.

To Reproduce
create a project with drf 3.10.3 (Django 2.2, Python 3.8/3.9)
Execute ./manage.py spectacular --file schema.yml

Expected behavior
I would expect the schema to pass smoothly

The same applies to 3.11.2 drf version

[tfranzel]

Hi,

every time this comes up, it is a different settings.py file used then what was assumed or a settings.py file that overrides what you originally had. This is usually due to environment variable DJANGO_SETTINGS_MODULE.

REST_FRAMEWORK = {
    # YOUR SETTINGS
    'DEFAULT_SCHEMA_CLASS': 'drf_spectacular.openapi.AutoSchema',
}

will 100% work. Just make sure you have the right settings file loaded.

[fannyhub]

thank you for such a quick reply. The variable seems not to be overriden:

[tfranzel]

That is the usual fallacy. running ./manage.py runserver and ./manage.py shell might load different settings depending on your setup. Sometimes simply by the prescence of a different DJANGO_SETTINGS_MODULE environment variable. It is a common issue. Try to use the debugger on your actual webserver process if possible. I'm quite confident it will be different in there.

[fannyhub]

Alas, it is not possible that we touch this variable. btw, we do not use runserver

[tfranzel]

Alas, it is not possible that we touch this variable.

not sure what that means.

btw, we do not use runserver

with runserver I meant your server process. Otherwise just try to print that variable to console in the process, where this happens.

Either you have some custom schema class on views OR your DEFAULT_SCHEMA_CLASS is not properly set in the environment. I cannot see any other explanation. Again, this has come up at least a dozen times. Every time it was a misconfigured settings.py. This works for hundreds of people without issue so it has to be something in your setup/environment I suppose.

[fannyhub]

Thank you very much for another reply. By not touching I meant that we didn't change the DEFAULT_SCHEMA_CLASS - it was introduced very recently, to see if transitioning to drf-spectacular was possible in our project.
The thing is that the problem disappears with the upgrade of rest framework to version 3.12.4 or 3.13 and schema gets generated. So I don't believe it depends upon our code. Please consider that some other users have encountered it, too and solved it by drf's upgrade: https://stackoverflow.com/questions/64545861/drf-spectacular-is-using-the-wrong-autoschema-to-generate-swagger . Furthermore, as the AssertionError is raised by the line (in drf-spectacular) assert isinstance(view.schema, AutoSchema) I found out that the view.schema is drf's ManualSchema. in version 3.10.3, ManualSchema usage in ObtainTokenView looks like that:

meanwhile in version 3.13.1 version of drf, this code looks as follows:

It seems that:

1. in the first case - i.e. drf 3.10.3. - the condition (if coreapi is not None and coreschema is not None) is True
2. while in the second case - i.e. drf 3.13.1 - (if coreapi.is_enabled() - the condition is False. In is_enabled() it is checked if api_settings.DEFAULT_SCHEMA_CLASS , is subclass of rest_framework.schemas.coreapi.AutoSchema. Debugging shows that api_settings.DEFAULT_SCHEMA_CLASS is drf_spectacular.openapi.AutoSchema.

[tfranzel]

https://stackoverflow.com/questions/64545861/drf-spectacular-is-using-the-wrong-autoschema-to-generate-swagger

Thanks @fannyhub for digging in. Sorry that I nudged you in the wrong direction repeatedly. 99% of raised&resolved issues were indeed wrong configs. I was not aware of that SO question and apparently nobody raised it here.

Your analysis is absolutely correct. It is indeed a bug in DRF < 3.12. I added an extension that fixes that bug for prior versions. It will be in the next release (0.24.0). Until then, you can easily fix it yourself by emulating what the extension will do:

        from drf_spectacular.openapi import AutoSchema
        from rest_framework.authtoken.views import ObtainAuthToken

        class FixedObtainAuthToken(ObtainAuthToken):
            schema = AutoSchema()

and using that in your urlpatterns instead of ObtainAuthToken/obtain_auth_token. Or you could simply copy&paste that extension for the time being.

[fannyhub]

Thank you, no more problems with creating schema :)

[kelvinmacharia254]

AssertionError: Incompatible AutoSchema used on View <class 'Vendors.views.PurchaseOrderListCreateView'>. Is DRF's DEFAULT_SCHEMA_CLASS pointing to "drf_spectacular.openapi.AutoSchema" or any other drf-spectacular compatible AutoSchema?

Still have this issue in Django reset 3.14.0 and drf_spectacular 0.27.0 .

I have have configured everything right as discussed here and as per documentation but no solution:

fork repo @:

https://github.com/Taruna21/Vendor_Management_System

[tfranzel]

this is an uncommon error and the message is exactly right. Some view, even from a library may set a custom schema class on a view and that provokes the error. If you are not doing it, some library does probably. This happened once before but I don't recall which lib. Maybe updating your libs will already fix the issue.

[kelvinmacharia254]

This is a recent project and has all the latest packages in my dependencies. Please run my code an see *Kind Regards,* *Kelvin Macharia*

…

On Mon, Jan 15, 2024 at 1:33 PM T. Franzel ***@***.***> wrote: this is an uncommon error and the message is exactly right. Some view, even from a library may set a custom schema class on a view and that provokes the error. If you are not doing it, some library does probably. This happened once before but I don't recall which lib. Maybe updating your libs will already fix the issue. — Reply to this email directly, view it on GitHub <#796 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6A3F6EGGTAJHXC4WJJEQF3YOUAWVAVCNFSM57VUII52U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBZGE4DEOJQGIYQ> . You are receiving this because you commented.Message ID: ***@***.***>

[tfranzel]

please find a minimal reproduction (the offending view) including stacktrace and create a new issue. I have very limited time to look at this.

[kelvinmacharia254]

Thanks, I will! *Kind Regards,* *Kelvin Macharia*

…

On Mon, Jan 15, 2024 at 2:16 PM T. Franzel ***@***.***> wrote: please find a minimal reproduction (the offending view) including stacktrace and create a new issue. I have very limited time to look at this. — Reply to this email directly, view it on GitHub <#796 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6A3F6ANRFWQWCVBT7B7XKTYOUFXRAVCNFSM57VUII52U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBZGE4TKNRUHA4A> . You are receiving this because you commented.Message ID: ***@***.***>