Extending a view class with an operation ID does not cause a system check error

[Lucidiot]

Describe the bug

Using @extend_schema on an view class with an operation_id results in an error being displayed on almost every manage.py command, yet the deploy check does not show any error, neither does a request on a SchemaView. This makes the issue undetectable in a CI job.

To Reproduce

Create an APIView class that uses @extend_schema with an operation_id, and make sure that it is imported somewhere that gets loaded early on, such as a urls.py:

# views.py
@extend_schema(operation_id='OhSnap')
class InfuriatingAPIView(RetrieveAPIView):
    ...

# urls.py
from leproject.leapp import views

You can then run manage.py check --deploy:

λ ./manage.py check --deploy
Error #0: using @extend_schema on viewset class InfuriatingAPIView with parameters operation_id or operation will most likely result in a broken schema.
System check identified no issues (0 silenced).

Some inspection using a traceback.print_stack() in GeneratorStats.emit shows that the error occurs while Django runs other system checks related to the ROOT_URLCONF; the views are imported too early for the check to work. Maybe the views need to be somehow reimported?

Expected behavior

The deploy check should show an actual warning:

λ ./manage.py check --deploy
System check identified some issues:

WARNINGS:
?: (drf_spectacular.W002) using @extend_schema on viewset class InfuriatingAPIView with parameters operation_id or operation will most likely result in a broken schema.

System check identified 1 issue (0 silenced).

[tfranzel]

hey @Lucidiot, sry for the delay. This is basically the same issue as #706. Below is the explanation from the other issue.

The issue is that we have in total 2 warnings that are emitted during decoration time. You found one! Everything else is emitted during schema generation time. Since we clear the warning/error cache prior to generation, the message shows up in the console but is subsequently lost. Since its cleared there is no reason to raise anymore.

I'll try to figure out how to save those warnings.

[tfranzel]

So this should fix the bug, but beware that you will still not get a non-zero status code like this.

We opted to emit all messages as warning, and check --deploy will only fail for error by default. To make check fail on schema warnings, you would need to lower the fail level like this:

drf-spectacular/tests/test_command.py

Line 68 in ef0d828

management.call_command('check', '--fail-level', 'WARNING', '--deploy')

[tfranzel]

closing this issue for now. feel free to comment if anything is missing or not working and we will follow-up.