Magento REST API : Configurable product with product links provided: "same set of attribute values" error

[JoryHogeveen]

Preconditions and environment

• Magento version: 2.4.7-p3
• Anything else that would help a developer reproduce the bug

Steps to reproduce

To be honest, I'm not sure how to reproduce this properly. There are cases where this happens and there are cases where it doesn't.

There are two related topics, both resulted in no further actions even though there are definitely cases where this occurs:
#33937
#16349

In my case I'm using the REST API to provide the linked product ID's.
The products that run into errors are validated several times and I can 100% confirm that these use different attribute values.
I also verified that the attribute value ID's are not even remotely similar (eg. 1456 vs 65 etc.) so some string comparison bug couldn't really be the issue here.

Another possibly important thing to note here is that the configurable product I tested against already exists in Magento.
Also, all these children (product links) are already linked to this product as well!

This REST API call is done in a loop which combines many product updates which could by anything. In this case there is no real change in the product links but since it's part of the update it is still send.

EDIT: Also not that when I add the child products manually through the Magento Admin interface I do not get the same error!

EDIT 2: I also verified the actual product results through the REST API and confirmed the attribute value IDs are not the same.

Expected result

Created product with links between parent and children products without exception.

Actual result

Got an exception, example:

"{"message":"Products \"%1\" and \"%2\" have the same set of attribute values.","parameters":[3155,3172]}"

Note:
Product 3155 has attribute value ID "1487"
Product 3172 has attribute value ID "45"

Additional information

Not sure if this would be relevant but these attributes have a LOT of option values, like about 500 options to choose from.
There are several other attributes as well (not used for configurations though) so the total number of attribute option IDs from different attributes is about 2000.

Release note

I've marked this as S0 since there is currently no way of going around this. It's simply not updating.

Triage and priority

• Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant]

Hi @JoryHogeveen. Thank you for your report.
To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce.

• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this
• To learn more about issue processing workflow, refer to the Code Contributions.

---

Join Magento Community Engineering Slack and ask your questions in #github channel.
⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
🕙 You can find the schedule on the Magento Community Calendar page.
📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

[JoryHogeveen]

I've done some digging in the code and what happens in the response and I think I've found the issue.

It seems that the contents of $attributeCodes was empty in Magento\ConfigurableProduct\Model\Plugin\ProductRepositorySave::validateProductLinks().

Note that I did not pass the configurable_product_options array since this product already exists and is configured. This is also not a required parameter according to docs. However, from what I can find so far, it appears that the REST API enforces you to pass this information otherwise it's empty and not automatically fetched from the current product config in ProductRepositorySave::beforeSave().

I verified this behavior by adjusting my API call to always include the config and yep, the update now works!

Of course I might have misinterpreted the documentation, but I was under the impression that you only need to produce the options when creating a configurable product, not when updating,
In case of updating, shouldn't it use the currently configured product options if this is not provided in the API request?

Hopefully somebody can provide some more insights on the inner workings of these endpoints.

Since there now is a workaround, I've changed the severity to S1