Problem/Motivation
#2864680: Spec Compliance: JSON API's schema disallows duplicate resource identifiers. EntityReferenceItems which reference the same entity must have an "arity" added an arity key to relationships returned by jsonapi to avoid an error when a reference field contains the same entity multiple times.
However, we have a similar problem when returning data about a specific field.
The previous fix only applies to ResourceIdentifier, but when querying a field, jsonapi returns normalized ResourceObject and those don't have an arity key.
Steps to reproduce
- Create an entity with a reference field and add the same entity multiple times in this reference field.
- Browse to
/jsonapi/[entity_type]/[bundle]/[uuid]/[field_name](real life example:/jsonapi/paragraph/carrousel/2f03a78f-1d0a-43e5-a6ee-6fb0fd8a90f7/field_images). - You get this error:
A JSON:API response failed validation (see the logs for details). Please report this in the issue queue on drupal.org
(However /jsonapi/[entity_type]/[bundle]/[uuid] does not have the same error because there, the relationship has arity keys.)
Proposed resolution
jsonapi should add an arity key on duplicated ResourceObject objects.
The arity logic from ResourceIdentifier should probably be refactorized to be used by other classes.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|
Issue fork drupal-3275497
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
prudloff commentedI pushed a commit that shows how to fix this in a very basic way.
However, a cleaner fix will probably require refactorizing parts of the code to reuse the existing
ResourceIdentifierlogic.Comment #4
bbralaHmm, that sounds like an oversight and I agree that should be identified as a bug.
Comment #7
prudloff commentedComment #12
prudloff commentedI need to fix related tests.
Comment #13
prudloff commentedThe MR adds the arity key to every resource even if not necessary (for example on responses containing a single resource).
It keeps the code simple and more predictable, but it means a lot of tests had to be updated.
Comment #14
smustgrave commentedLeft comments/questions in MR.
Comment #15
prudloff commentedI answered the questions.
If this needs fixing, we should probably fix it in JsonApiResource as well?
Comment #16
smustgrave commentedAll the tests having to be updated to pass makes me think we are introducing a breaking change
Comment #17
bbralaKinda depends, adding a meta to add responses does mean we are doing a change. Is it breaking? If your client support jsonapi it shouldn't be, its part of the spec.
So i lean towards not breaking.
Comment #18
smustgrave commentedCan we add an example where it’s not passed to make sure both ways are covered?
Comment #19
bbralaIt's late. Is this also for creating entities? If so, then it should also work without, otherwise it is indeed a BC break since you might not do that :x
Comment #20
smustgrave commentedNot sure correct status but just thinking if we can add an example mentioned in #18
Comment #21
prudloff commentedThe MR only adds the arity key to read responses, it does not change the requirements for creating/editing entities.
I did not change the tests for these operations so if they pass it probably means it still works without an arity key.
(However we could have a followup to allow specifying arity when editing a reference field with duplicates, in order to specify which of the references we want to change.)
I'm not sure it is a breaking change. If your client does not use the arity key, it will continue to work as before.
The main change is that now a response can contain the same entity multiple times.
I agree that changing all these tests does not feel optimal. An alternative solution would be to only add the arity key when the response contains the same entity multiple times but it might make the code more complex and less predictable for a small benefit.
Comment #22
smustgrave commented@bbrala that work for you?
Comment #23
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #24
prudloff commentedI rebased the MR.
Comment #25
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #26
prudloff commentedI rebased the MR again.
Comment #28
bbralaSorry for the late reponse. I think that would be ok to tranparantly do this. Don't see how that would create issues. Clients will be OK, only see possible issues in tests which would do a full compary of the output. Doesn't seem like a problem.
I discussed the fact we are adding 0 to existing also with casey. We do think this will not result in issues since its in the meta. Also looking at how the count is done, that also seems fine.
What I'm kinda wondering, we should probably also have at least some sort of test for the meta data. Seems we can so that easily here? Perhaps even patching with artity also (although maybe not for every entity type) to see if that works?
Added casey because we sat down together to disect the possible implications.
Comment #29
bbralaComment #30
prudloff commented@bbrala The MR already has some tests that check arity keys in JsonApiFunctionalTest:
https://git.drupalcode.org/project/drupal/-/blob/868a9723aea3a084a2f8714...
https://git.drupalcode.org/project/drupal/-/blob/868a9723aea3a084a2f8714...
(The code you are pointing to is about /jsonapi/node/article/[uuid]/relationships/[field_name] but this MR is about/jsonapi/node/article/[uuid]/[field_name] (relationships already have arity keys that are added only when the relationship contains the same entity twice).
I added some arity keys to write tests (POST and PATCH) to make sure it does not break anything to send this key.
Comment #31
bbralaThink this is all good. I considered if we need to make sure we have tests with and without, but don't think that is an issue. Also considered if we should actually validate the arity key to be >0 and int in
withArity, but i think that is a little overkill.Fine to get artity in meta this way to release that info. We do need a change records that tells developers we are adding this. After that RTBC is fine.
Comment #32
bbralaComment #35
prudloff commentedI see bbrala added a CR.
Comment #36
bbralaI was waiting for the tests and forget oops, thanks!
Comment #37
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #38
bbralaLOcally this phpstan error is not present. Also looking at the arguments, i see there might be confusion on the interface vs concrete classes, but they do end up at the same end results. Gonna ignore the bot for now.
Comment #39
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.