When viewing a product the current_store is not returning the correct store

If not current (active) store is set, it falls back to the default store.

You can implement something like this to set up multiple stores for a user: https://docs.drupalcommerce.org/commerce2/developer-guide/stores/resolve...

A example how to fix this issue might be seen on the Commerce Multistore module:

https://github.com/drugan/commerce_multistore/blob/master/src/Resolver/M...

The store resolved for a product is the default store of the product owner. But, yes it might happen that the product assigned to some of the owner's stores which is different from the default one.

Well, the code need to be updated in order to prevent this issue...

I am talking about a case with a product assigned to a single store that is not the default one.

Note that with the Multistore module each store owner has their own default store. So, it is impossible for an owner of only one store to not have a default store. Seems that store resolver from my previous comment should work in this case.

...adding a product to cart and the availability manager both resolve correctly while \Drupal::service('commerce_store.current_store')->getStore() does not

I believe this happens because the current store resolver totally relies on the current request and its parameters one of each is the right store in the case of add to cart or availability manager. As for the \Drupal::service('commerce_store.current_store')->getStore() it depends in what context this service is called. Is there any store in the context? Who is the current user? An order owner? A product owner? So, obviously if there is nothing to dig in to properly resolve a store then the result might be unexpected. If no one of the resolvers returned a store then the global default store is returned. But, in the current DC even that may not give a store. Just because having a default store on a site optional and you might end up with a NULL as a default store. Only when you first time assigned any store as a default then it can't be reverted. Assigning another default store just takes away this property from the previous one.

The Commerce Multistore fixes this and some other DC critical issues. Having a default store is forced both for the global default store as well for each store owner's default store. It's done when the first store is saved. But, even if the default store is removed, anyway, the Multistore version of store storage class returns the last store found either for an admin as a global default store or for a store (product) owner who may own multiple stores.

@guy_schneerson

If you fixed your issue with the commerce_store_selector module then it could be closed. As for me it seems more like akinda architectural issue which cannot be solved just applying one more store resolver or similar solution. It should be fixed as a set of different interrelated issues. When working on the Multistore module I've also stumbled on that we never can be sure that the product (variation) added to the right store or a store does not change its data without breaking existing products on the store.

Only thing i found in commerce core during review/testing the commerce_stock module: (with a custom view listing products per current store)

Error: Call to a member function id() on null in Drupal\commerce_store\Plugin\views\argument_default\CurrentStore->getArgument()

When no default store is set in config \Drupal::service('commerce_store.current_store')->getStore() returns null, but the 'current store' views argument handler breaks the site with the above error.

So small followup issue could be: make sure the store in the views argument handler is set before using it. (the store edit form already sets the default checkbox to checked and disables it if no default store exists, but the views handler just uses it. Maybe just something to be aware of.)

Commerce stock should make sure i think the default store is actually set, i'll comment when i review the pr and locate this issue. (delete your default store config to test if it breaks due to this, then we might want to start working on this)

Closing issue as WAD, please reopen if you have any additional questions, comments, etc.

And should be SR.