Incorrect configuration scope is occasionally returned when attempting to resolve a null scope id

[matthew-muscat]

Preconditions

1. Magento v2.2.x and Magento v2.3-develop are affected
2. PHP v7.1

Steps to reproduce

1. Setup a multi-store magento installation
2. Setup a configuration value that is specific to a particular store scope
3. Using environment emulation, emulate a store id and then attempt to retrieve the store configuration property using \Magento\Framework\App\Config\ScopeConfigInterface::getValue($configPath, 'stores')

Expected result

• When working in a multi-store environment...
  -- The correct configuration value is retrieved based on the current store scope
  -- The correct configuration value is retrieved based on the currently emulated store environment

Actual result

• The value returned for the configuration will be that of the default store scope, rather than the current / emulated store id.

Root cause

• The ScopeCodeResolver::resolve method is not suitably handling a null scopeId value https://github.com/magento/magento2/blob/2.2-develop/lib/internal/Magento/Framework/App/Config/ScopeCodeResolver.php#L40, this is due to a class property cache key of "$scopeCode" being null
• A null value in the array of resolvedScopeCodes[$scopeType][$scopeCode] is being used, which may return an incorrect scope - typically this is the default scope

Proposed fix

• The $scopeCode value that is used in the resolvedScopeCodes array should be replaced with the $resolvedScopeCode, ensuring the array is populated correctly and avoids returning an incorrect value when null is passed as the desired $scopeId
• Additionally, the conditional checks used on the $scopeCode value can be avoided, as it does not appear to influence the result

[magento-engcom-team]

Hi @matthew-muscat. 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-engcom-team give me {$VERSION} instance

where {$VERSION} is version tags (starting from 2.2.0+) or develop branches (2.2-develop +).
For more details, please, review the Magento Contributor Assistant documentation.

@matthew-muscat do you confirm that you was able to reproduce the issue on vanilla Magento instance following steps to reproduce?

• yes
• no

[engcom-backlog-nickolas]

Hello @matthew-muscat, thank you for your report and pull request.
We've acknowledged the issue and added to our backlog.

[matthew-muscat]

@magento-engcom-team give me 2.2.5 instance

[magento-engcom-team]

Hi @matthew-muscat. Thank you for your request. I'm working on Magento 2.2.5 instance for you

[magento-engcom-team]

Hi @matthew-muscat, here is your Magento instance.
Admin access: https://i-16939-2-2-5.engcom.dev.magento.com/admin
Login: admin Password: 123123q
Instance will be terminated in up to 3 hours.

[matthew-muscat]

@engcom-backlog-nickolas - this one's a little difficult to repeat in the test instance, as it requires a multistore setup and either environment emulation or store scope switching.

My process to verify and repeat the issue has been to use environment emulation, then using the ScopeConfigInterface::getValue to retrieve a value using just the $path and $scope params (ie: no scopeId is passed) — you'll see the incorrect value is returned, due to the ScopeCodeResolver::resolve() method not handling the null scopeId value

[engcom-backlog-nickolas]

@matthew-muscat thank you for help. I've reproduced this issue locally. Thanks again for pull request.

[magento-engcom-team]

Hi @matthew-muscat. Thank you for your report.
The issue has been fixed in #16940 by @matthew-muscat in 2.2-develop branch
Related commit(s):

• d79cfa9009034d8df1a37587ecbed2d62225d3d6
• a9c483885aaa4f47fa8eb1b8174e10cd6f7b78dd
• 93edb382ab25fa01b7e50a76ccee0b6936de2679

The fix will be available with the upcoming 2.2.8 release.

[Axel29]

Hello,

This fix should have been present since 2.2.8 but I can't see it in 2.3.0.

[magento-engcom-team]

Hi @matthew-muscat. Thank you for your report.
The issue has been fixed in #21633 by @mage2pratik in 2.3-develop branch
Related commit(s):

• bc8f90993c35b5c232a923ef126ba97d046a35c0
• ca168091922bc4d34e2347304abb12e9f08a81f9
• 9e5fdbbb0edbaceea6d5a17607dea1a21205286c
• e2ce2435d95af233dc218a20f1a58bedb3ab97b1

The fix will be available with the upcoming 2.3.2 release.