Django-rest-framework: Duplicate OpenAPI operation IDs when there are multiple generic view sets for the same model

[reupen]

Checklist

• [x] I have verified that that issue exists against the master branch of Django REST framework.
• [x] I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
• [x] 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.)
• [x] 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. Define two generic view sets for the same model. E.g.:

   class PersonV1(ModelViewSet):
       queryset = Person.objects.all()
       serializer_class = PersonV1Serializer
   
   class PersonV2(ModelViewSet):
       queryset = Person.objects.all()
       serializer_class = PersonV2Serializer
   

   (There are multiple reasons why you might do this e.g. old and new versions, different filtering, different audiences...)

2. Enable OpenAPI schema generation

Expected behavior

The operationID values generated are unique as required per the OpenAPI spec.

Actual behavior

The operation IDs are the same for both sets of views. (One problem this causes is that clicking on the operation in Swagger UI causes both operations to expand together.)

Discussion and possible solutions

The operation IDs generated are in the form of <action><model name> i.e. ListPerson etc. (The logic is in AutoSchema._get_operation_id.)

I think it is going to be difficult to come up with a pattern for generating meaningful unique names in all cases. However, there should be some effort to make sure that the generated operation IDs are unique.

One possible solution would be to:

1. Detect duplicates.

2. Append an automatically-generated suffix in such cases.

   This could, perhaps, be the first 8-characters of a hash of the view's dotted module path (i.e. {view.__module__}.{view.__name__}).

   (The reason for the suggestion of a hash is so that it is, at least, reasonably stable.)

[carltongibson]

Ok, happy to look at any PRs here, but my initial thought is that you can/should provide an AutoSchema subclass, for at least one of the ViewSets.

(Tricky one...)

[n2ygk]

My workaround -- in this
https://github.com/django-json-api/django-rest-framework-json-api/blob/ab25fb96911d293491245b7024996536e100c345/rest_framework_json_api/schemas/openapi.py#L479-L490
DJA PR (still WIP) -- was to just name the operationIds based on path.
These IDs are rarely if ever actually used for anything anyway, so their
value just needs to be unique and not necessarily descriptive.

Per your direction, I would eventually expect to move this code out of DJA
and into DRF as a PR, although I look forward to any other way to generate
unique operationIds.

On Mon, Jul 29, 2019 at 9:35 AM Carlton Gibson [e-mail]
wrote:

Ok, happy to look at any PRs here, but my initial thought is that you
can/should provide an AutoSchema subclass, for at least one of the ViewSets.

(Tricky one...)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/encode/django-rest-framework/issues/6844?email_source=notifications&email_token=ABBHS53M33EZFMLWRZ4QOSTQB3WYPA5CNFSM4IHSCDXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3AW7TQ#issuecomment-515993550,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABBHS56VFC5HX3APHSK65HTQB3WYPANCNFSM4IHSCDXA
.

[Jufik]

I think we should at least raise an error, and give the possibility to declare part of operationId

Couldn't we add some class attributes to handle make help out with _get_operation_id?
On my side, I have some models like "Address" ending up with operationId like "listAddresss"...

I'm think about declaring "operation_name" and "operation_name_plural" in Views to make things explicit, and to add some errors around here to ask for specific declaration?

Edit:Just some my suggestion is basically referenced here

[carltongibson]

Couldn't we add some class attributes to handle make help out with _get_operation_id?

You could easily do that in an AutoSchema subclass.

Whether it's worth the extra noise in the API for the default case, I'm not sure.

Best approach is to implement it, post your example here for others, and then we can discuss.

[gnuletik]

This issue should be resolved in the 3.12 release thanks to the following PRs:

• Customize the operation_id_base (see docs in the PR)
• Harmonize operationId with camelCase
• Warns users about duplicated operationId

Feel free to try the master branch before release!
I'd be glad to get some feedback!