Product variation attributes shows combines variations that not exist.

I'm not sure what you mean.
Can you be more specific? Which variations did you create, with which attribute values, and what's the output you're seeing?
Screenshots would also help.

I see what you mean now. Looks like a bug in our optional attribute handling.

wqmeng , thanks for sharing the edit screen, will make it easier to reproduce and test!

Such problems appear as well when changing the order of Attributes for display in "Product variation types". Similar issue was reported before, see https://www.drupal.org/node/2707721

PR: https://github.com/drupalcommerce/commerce/pull/425

still work in progress

I can confirm the bug. Tried a bunch of different configurations with (optional) attributes and the dynamic attribute form gives strange results. Sometimes non-existing attributes show up (as in #4), sometimes the attribute-selector disappears.

It is a really hard problem to solve.
Here is a simple case that seems 'unsolvable' for the dynamic widget.

We have a computer-product with an optional screen and an optional hard-disk.
Screen has sizes: 13inch or 15inch
Hard-disk has sizes: 1TB and 2TB

We create a Product "Computer" that has just 2 Variations:
variation_1: 13 inch screen, no hard-disk
variation_2: no screen, 1 TB hard-disk

Now I visit the product-page, what should happen?
If the dynamic form starts with variation_1:
Should it show a dropdown to select the 1 TB hard-disk?
If I selected it, my 13 inch screen would vanish. That's not good.

This is a deadlock that cannot be solved within by dynamic widget UX.

If we change the optional attribute to required. And instead of keeping the screen or hard-disk empty we give it an attribute value "Nothing" the problem stays. So this has nothing to do with optional attributes.

As a suggestion I think we should provide a fallback for the dynamic form if the attribute-combinations are 'unsolvable'. 'Unsolvable' means that variations are 'unreachable' or 'mutually exclusive'.
How to resolve if attribute-combinations are 'unsolvable' is an interesting question.

A 'safe' fallback could be a radio-list of all variations.

My suggestion would be to first:
- Create a mechanism to resolve 'mutually exclusive' variations and the fallback to the variation-radio-button form.
- After that kill the bugs within the dynamic attribute form.

Alright, added 2 tests to clarify #10

PR: https://github.com/drupalcommerce/commerce/pull/425
- testMutuallyExclusiveAttributeMatrixTwoByTwo
- testMutuallyExclusiveAttributeMatrixTwoByTwobyTwo

The first one works well with these variations:

$attribute_values_matrix = [
      ['one', 'x'],
      ['x', 'alpha'],
    ];

See this gif: https://www.drupal.org/files/issues/testMutuallyExclusiveAttributeMatrix...

The seconds one fails with these variations:

$attribute_values_matrix = [
      ['one', 'x', 'x'],
      ['x', 'alpha', 'x'],
      ['x', 'x', 'milano'],
    ];

See this gif: https://www.drupal.org/files/issues/testMutuallyExclusiveAttributeMatrix...

Put this on needs-review so we can discuss next steps.

The PR (https://github.com/drupalcommerce/commerce/pull/425) posted can't be pushed to as maintainers and is severely outdated. Posting patch of lastest PR changes here.

Needs rebase and revaluation.

@wqmeng

I've tested your issue using this solution and seems it works. Also note that based on the solution I've created only one Hard Disk attribute and then only duplicated it on the variation type edit form. Here it is explained how to do it.

First, I've created your variations:

And that's what I've got:

The solution linked on #16 was mostly rewritten in order to make an attempt to resolve mutually exclusive attributes issue. The notation of two additional default dummy options for optional attributes is introduced. One is a kind of No, Thanks! option which enables to make intentionally empty choice on an attribute. Another is No options available ... is just a placeholder for the case when variation has no any option for the given attributes combination. It improves UX as I think. The default labels for the options can configured on the Commerce select list widget. Also, the display of the No options available ... placeholder may be disabled on the widget. The settings need to be set for each attribute field individually, but if you are happy with default labels you do need to do anything. You even don't need to change the standard Select list widget.

For the test purposes I've created computer-product variations like on the #10 comment.

And that's what I've got: https://www.drupal.org/files/issues/ndf_computer.gif

Also, I've created MutuallyExclusiveAttributeMatrixTwoByTwobyTwo variations.

All the No options available ... placeholders were disabled on the Commerce select list widget settings.

And that's what I've got: https://www.drupal.org/files/issues/TwoByTwobyTwo.gif

Please, report test cases which don't work with the current solution so we together will try to improve it.

This issue is now fixed on the Commerce Correct Attributes submodule of the Commerce Extended Attributes.

Okay, working on this. Changes attribute to alpha/omega and one/two for easier review. Tests still fail. This will solve some root logic errors.

The main fail is the fact we do not reconcile the attributes, which causes a critical error because the purchased entity is null, or something whacky like that happens.

Okay, fixed the patch. It was old enough that the price definitions were wrong.

This should fail at

1) Drupal\Tests\commerce_cart\FunctionalJavascript\AddToCartOptionalAttributeTest::testMutuallyExclusiveAttributeMatrixTwoByTwobyTwo
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'x'
+'alpha'

Okay, updated test. This fails due an option being selectable which should not.

Given

      ['one', 'omega', 'pancevo'],
      ['two', 'alpha', 'pancevo'],
      ['two', 'omega', 'milano'],

If I pick “one”, then “omega” attributes. my only city attribute option should be “pancevo” correct? because only one variation has “one, omega”. If I chose “milano” it would reset all of my choices, which should not be allowed.

This should error with

Behat\Mink\Exception\ExpectationException: An element matching xpath "//select[@name="purchased_entity[0][attributes][attribute_city]"]//option[@value="5"]" appears on this page, but it should not.

because Milano is an option.

The test won't run. But here is output

$ ../bin/phpunit -c core/phpunit.xml modules/contrib/commerce/modules/cart/tests/src/FunctionalJavascript/AddToCartOptionalAttributeTest.php --stop-on-failure --debug --group debug
PHPUnit 4.8.36 by Sebastian Bergmann and contributors.


Starting test 'Drupal\Tests\commerce_cart\FunctionalJavascript\AddToCartOptionalAttributeTest::testMutuallyExclusiveAttributeMatrixTwoByTwobyTwo'.
E

Time: 1.14 minutes, Memory: 6.00MB

There was 1 error:

1) Drupal\Tests\commerce_cart\FunctionalJavascript\AddToCartOptionalAttributeTest::testMutuallyExclusiveAttributeMatrixTwoByTwobyTwo
Behat\Mink\Exception\ExpectationException: An element matching xpath "//select[@name="purchased_entity[0][attributes][attribute_city]"]//option[@value="5"]" appears on this page, but it should not.

/Users/mglaman/Drupal/sites/commerce2x/vendor/behat/mink/src/WebAssert.php:770
/Users/mglaman/Drupal/sites/commerce2x/vendor/behat/mink/src/WebAssert.php:445
/Users/mglaman/Drupal/sites/commerce2x/web/modules/contrib/commerce/modules/cart/tests/src/Functional/CartBrowserTestBase.php:125
/Users/mglaman/Drupal/sites/commerce2x/web/modules/contrib/commerce/modules/cart/tests/src/FunctionalJavascript/AddToCartOptionalAttributeTest.php:193

FAILURES!
Tests: 1, Assertions: 29, Errors: 1.

Unfortunately Drupal 8.5 is making this hard to run tests locally. I need to post a WIP patch.

Postponing until we sort out the patch in https://www.drupal.org/project/commerce/issues/2707721#comment-12523559.

I'm pretty sure both issues are the same bug. I posted a patch meant for here over there. Postponing this one until that issue is sorted out, just to help stay organized.

Closing as a duplicate of #2707721: Incorrect display of attribute field values on the Add To Cart form , since that issue now covers this issue (we have a "wqmenq" test case which is passing).