Checklist

• I have verified that that issue exists against the master branch of Django REST framework.
• I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
• This is not a usage question. (Those should be directed to the discussion group instead.)
• This cannot be dealt with as a third party library. (We prefer new functionality to be in the form of third party libraries where possible.)
• I have reduced the issue to the simplest possible case.
• I have included a failing test as a pull request. (If you are unable to do so we can still accept the issue.)

Steps to reproduce

1. Create a view set mixin with a custom action that specifies a custom schema and use it on two view sets.

   For example:

   class CancelViewSetMixin:
       # For simplicity, `AutoSchema` is used in this example, but this could be any schema class
       @action(methods=['post'], detail=True, schema=AutoSchema())
       def cancel(self, request, pk):
           return Response()
   
   
   class ViewSetA(CancelViewSetMixin, GenericViewSet):
       serializer_class = ModelASerializer
       queryset = ModelA.objects.all()
   
   
   class ViewSetB(CancelViewSetMixin, GenericViewSet):
       serializer_class = ModelBSerializer
       queryset = ModelB.objects.all()

2. Register the routes e.g.

   router = DefaultRouter()
   router.register(r'view-set-a', ViewSetA)
   router.register(r'view-set-b', ViewSetB)
   
   
   urlpatterns = [
       path('', include(router.urls)),
   ]

3. Run ./manage.py generateschema

Expected behavior

Different schemas generated for the cancel action in the two view sets.

Actual behavior

The same schema is generated for the cancel action in the two view sets (basically everything except the path are the same, so operationId, request schema, responses etc. are all shared).

Discussion

(There is some background to the general topic in #5992.)

This does not work as desired because same view instance ends up being used for schema generation for the two actions (but the correct path and method are used).

The fact that this doesn't work is probably not too shocking considering that view is an attribute of the schema instance, but it would be good if it did work.

It's also interesting to note that setting a schema on a base class using the schema attribute does work. There is a difference in when ViewInspector.__set__() is called in the two cases.

My first thought would be that it would be simpler to eliminate the state from schema classes and pass the view into the schema_class.get_operation() as an argument instead. Of course, there is a backwards compatibility consideration there.

Simply explicitly setting view on the schema instance before calling get_operation() also works (but perhaps a bit on the hacky side).