M2 suggests running setup:upgrade if version number of module is higher than expected

[chickenland]

This appears to be an issue that is highlighted whilst using different versions of a module within source control, where there is a different version of a module in another branch.

When you update a module, and then switch branches to a branch with a lower version number, Magento throws an exception prompting the user to run bin/magento setup:upgrade.

\Magento\Framework\Module\DbVersionInfo::isModuleVersionEqual appears to check for equality to current version number.

Running setup:upgrade in this instance appears to do nothing.

I can't think of a reason why this has been done this way (I guess future versions of a module could update the database and then become incompatible with an earlier version?) - perhaps it's just the exception message that needs to change?

Preconditions

1. Magento 2.1.7

Steps to reproduce

1. Create a new module and give it a low version number
2. Branch
3. Update module with new installer, bump installer
4. Run bin/magento setup:upgrade
5. Switch to original branch

Expected result

1. Site to continue working

Actual result

1. Exception thrown. Example below.

1 exception(s):
Exception #0 (Magento\Framework\Exception\LocalizedException): Please upgrade your database: Run "bin/magento setup:upgrade" from the Magento root directory. 
The following modules are outdated:
xxxx_yyyy schema: current version - 0.7.0, required version - 0.5.0
xxxx_yyyy data: current version - 0.7.0, required version - 0.5.0

Exception #0 (Magento\Framework\Exception\LocalizedException): Please upgrade your database: Run "bin/magento setup:upgrade" from the Magento root directory. 
The following modules are outdated:
xxxx_yyyy schema: current version - 0.7.0, required version - 0.5.0
xxxx_yyyy data: current version - 0.7.0, required version - 0.5.0
#0 /private/var/www/websiteabc/http/vendor/magento/framework/Interception/Chain/Chain.php(67): Magento\Framework\Module\Plugin\DbStatusValidator->aroundDispatch(Object(Magento\Framework\App\FrontController\Interceptor), Object(Closure), Object(Magento\Framework\App\Request\Http))
#1 /private/var/www/websiteabc/http/vendor/magento/framework/Interception/Chain/Chain.php(63): Magento\Framework\Interception\Chain\Chain->invokeNext('Magento\\Framewo...', 'dispatch', Object(Magento\Framework\App\FrontController\Interceptor), Array, 'front-controlle...')
#2 /private/var/www/websiteabc/http/vendor/magento/module-page-cache/Model/App/FrontController/VarnishPlugin.php(55): Magento\Framework\Interception\Chain\Chain->Magento\Framework\Interception\Chain\{closure}(Object(Magento\Framework\App\Request\Http))
#3 /private/var/www/websiteabc/http/vendor/magento/framework/Interception/Chain/Chain.php(67): Magento\PageCache\Model\App\FrontController\VarnishPlugin->aroundDispatch(Object(Magento\Framework\App\FrontController\Interceptor), Object(Closure), Object(Magento\Framework\App\Request\Http))
#4 /private/var/www/websiteabc/http/vendor/magento/framework/Interception/Interceptor.php(138): Magento\Framework\Interception\Chain\Chain->invokeNext('Magento\\Framewo...', 'dispatch', Object(Magento\Framework\App\FrontController\Interceptor), Array, 'front-controlle...')
#5 /private/var/www/websiteabc/http/vendor/magento/module-page-cache/Model/App/FrontController/BuiltinPlugin.php(68): Magento\Framework\App\FrontController\Interceptor->Magento\Framework\Interception\{closure}(Object(Magento\Framework\App\Request\Http))
#6 /private/var/www/websiteabc/http/vendor/magento/framework/Interception/Interceptor.php(142): Magento\PageCache\Model\App\FrontController\BuiltinPlugin->aroundDispatch(Object(Magento\Framework\App\FrontController\Interceptor), Object(Closure), Object(Magento\Framework\App\Request\Http))
#7 /private/var/www/websiteabc/http/var/generation/Magento/Framework/App/FrontController/Interceptor.php(26): Magento\Framework\App\FrontController\Interceptor->___callPlugins('dispatch', Array, Array)
#8 /private/var/www/websiteabc/http/vendor/magento/framework/App/Http.php(135): Magento\Framework\App\FrontController\Interceptor->dispatch(Object(Magento\Framework\App\Request\Http))
#9 /private/var/www/websiteabc/http/vendor/magento/framework/App/Bootstrap.php(258): Magento\Framework\App\Http->launch()
#10 /private/var/www/websiteabc/http/pub/index.php(37): Magento\Framework\App\Bootstrap->run(Object(Magento\Framework\App\Http))
#11 {main}

[southerncomputer]

What if the architecture of the tables/data change and you revert back to an older version (of magento/of module) - you wouldn't be warned until a schema failure/logical data failure occurs?

It would be nice if magento allowed you to roll back changes in such a case!

[chickenland]

@southerncomputer Yes - this is the only reason I could imagine as mentioned above. In my case this isn't an issue, but I could see that this might be the reason for larger/public modules.

If there was an encouragement to use SemVer, would it be unreasonable to expect M2 to check the major version and potentially inforce this logic, but ignore it on minor/patch versions?

[korostii]

Current behavior clearly needs to be changed (at the very least, the exception message has to be less confusing).

[magento-team]

Internal ticket to track issue progress: MAGETWO-80225

[magento-engcom-team]

Hi @chickenland the issue has been fixed in #11064 by @schmengler . The fix will be available in 2.2.1

[okorshenko]

Hi @chickenland. Thank you for your report.
The issue has been fixed in magento-engcom/magento2ce#1353 by @magento-engcom-team in 2.3-develop branch
Related commit(s):

• 299109f
• 57318bf
• 41cd961
• 076b903
• 435a6c2
• 5d174b8
• a47b10d
• ab48cb1
• 46be4c7
• eafc6f0
• 63b9e90
• 2edfe9a
• ef5ddff
• 4ada797
• c5d9a01
• 72e9e07
• 215180d
• 685d506

The fix will be available with the upcoming 2.3.0 release.