GraphQL query returns admin option value label within aggregations

[magento-engcom-team]

Issue

Product attribute option labels that are set for the Admin are also returned by the products GraphQL query, instead of option labels for the Default Store View.

For example, if you set the label for the "Yoga" option for the "Activity" product attribute to different values for the Admin versus the Default Store View, the store frontend will show the Default Store view label, whereas a GraphQL query will return the Admin label. 

Steps to Replicate

1. Create a new Magento instance with sample data (the merchant did this in clean 2.3.5 and 2.4-develop, and we confirmed in 2.3-develop)
2. Note how the Activity_ product attribute has an option called _Yoga:
   !https://support.magento.com/attachments/token/5iLCI4P036962Ch5jX4CVzIjC/?name=ScreenShot2020-05-15at2.12.58PM.png|width=820,height=453!
3. In the admin dashboard, go to Stores -> Attributes -> Products.
4. Click the "activity" attribute to edit it
5. Go to Manage Options and set a different value for Admin and Default Store View:
   !https://support.magento.com/attachments/token/XIvqqfxSylYtm1CBDourD8VOf/?name=ScreenShot2020-05-15at2.14.25PM.png|width=764,height=596!
6. Save changes and clear cache
7. Compare the store view to a GraphQL query that shows the Activity label and options:
   !https://support.magento.com/attachments/token/3sBU89qfzjWyDkxkiPC0gs1lD/?name=ScreenShot2020-05-15at2.16.38PM.png|width=817,height=450!

Expected Results

The label for Yoga should be the same in the frontend store view and the GraphQL query

Actual Results

The store view shows the Default Store View label whereas the GraphQL query shows the Admin label

Notes

As seen in the above and below screenshots, the merchant observes that when an Admin label is created, the associated entry in the eav*attribute_option_value table has a higher value_id, and another store*id is also created, even when there is just one store. They suspect that this is buggy behavior contributing to the issue.

!https://support.magento.com/attachments/token/BNNQyom0lftsiJRy7L7Zm71bT/?name=ScreenShot2020-05-06at5.08.40PM.png!
 

They also shared the following comments:
{quote}The reason is Magento\CatalogGraphQl\DataProvider\Product\LayeredNavigation\AttributeOptionProvider::getOptions method retrieving all the values for the option without respecting what store it should bring this result. If you stop your debugger in Magento\CatalogGraphQl\DataProvider\Product\LayeredNavigation\AttributeOptionProvider::formatResult and watch processed data, you will see that Magento processes "English Yoga" first, sets the result as "English Yoga" then iterates to next item and processes "Admin Yoga" and overrides result as "Admin Yoga". As you can see on my screenshot, eavattribute_option_value table shows a higher value_id for store_id=0, so Admin Yoga gets processed last. If I make store_id=1 valueid 10000, it gets processed last and then I see "English Yoga" on my result. If I would create another store view and assign value for it, then that value could have a different value but this method wouldn't also respect to Store header being sent for multi-store setups, but that's a secondary issue. This even doesn't work with single store setups.
{quote}

Example GraphQL query

query myProducts ($currentPage: Int = 1 $pageSize: Int!){
  products(pageSize: $pageSize, currentPage: $currentPage, search:"Yoga"){
    aggregations{
      attribute_code
      label
      options{
        label
        value
      }
    }
  }
}

// Query vars
{
  "currentPage": 1,
  "pageSize": 4
}```

[m2-assistant]

Hi @magento-engcom-team. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• Summary of the issue
• Information on your environment
• Steps to reproduce
• Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

Please, add a comment to assign the issue: @magento I am working on this

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[m2-assistant]

Hi @gallyamov. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: 👇

• 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
     Details

     If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.
• 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.
• 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.
• 4. Verify that the issue is reproducible on 2.4-develop branch
     Details

     - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
     - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
     - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[danielrenaud]

@gallyamov This ticket seems to be related, and maybe the same issue: #28572