Preconditions and environment

• Magento 2.4.7-p6

• Product attribute with multiple store_labels (e.g., for France and Germany)

• Asynchronous or sequential update of attribute option using:
  PUT /rest/all/async/bulk/V1/products/attributes/byAttributeCode/options/byOptionId

• Magento’s implementation of the saveOption() method in \Magento\Eav\Model\Entity\Attribute\OptionManagement overwrites existing store-specific labels (store_labels) when an update is made, instead of merging the changes. As a result, labels for other store views are unintentionally removed when not explicitly included in the update payload.

Steps to reproduce

1. Create or ensure a product attribute option has the following setup:

• option_id = 1234
• Labels:
  - Store ID 2 (France): "Bleu"
  - Store ID 3 (Germany): "Blau"

2. Call the API to update only the French label:

{
  "option_id": 1234,
  "store_labels": [
    {
      "store_id": 2,
      "label": "Bleu updated"
    }
  ]
}

3. Next call, update only the German label:

{
  "option_id": 1234,
  "store_labels": [
    {
      "store_id": 3,
      "label": "Blau updated"
    }
  ]
}

4. Observe that after the second update, the French label is removed (set to blank)

Expected result

• The store_labels for France should remain intact after the Germany label is updated.
• Magento should merge the provided labels with existing ones instead of fully overwriting them.

Actual result

The second update overwrites the entire set of store_labels, removing any store-specific labels not included in the request.

Additional information

The method \Magento\Eav\Model\Entity\Attribute\OptionManagement::saveOption() constructs a new options['value'][$optionId] array and replaces all existing labels. There is no merging logic, and missing labels are effectively erased.

Relevant code snippet:
$options['value'][$optionId][0] = $optionLabel; foreach ($option->getStoreLabels() as $label) { $options['value'][$optionId][$label->getStoreId()] = $label->getLabel(); }

Release note

No response

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”.