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.