[2.4.6-p2] Regression, can trigger error 'Connection "default" is not defined' again #37805
Comments
|
Hi @hostep. Thank you for your report.
Join Magento Community Engineering Slack and ask your questions in #github channel. |
m2-community-project
bot
added this to Ready for Confirmation
in Issue Confirmation and Triage Board
|
Hi @engcom-Dash. Thank you for working on this issue.
|
ihor-sviziev
added
the
Priority: P1
m2-community-project
bot
removed this from Ready for Confirmation
in Issue Confirmation and Triage Board
|
@hostep @engcom-Charlie I think we should add some automated test coverage for such case to prevent such regressions in the future |
m2-community-project
bot
moved this from Dev In Progress
to Ready for Development
in High Priority Backlog
github-jira-sync-bot
added
Progress: PR in progress
and removed
Progress: ready for dev
labels
m2-community-project
bot
moved this from Ready for Development
to Pull Request In Progress
in High Priority Backlog
|
@hostep could you please let me know if you are still working on this issue? thank you! |
|
@alzota: what do you mean? I'm not working on this issue, did I say I would maybe? I see a label got added |
|
@hostep thanks for confirmation. the label "Progress: PR in progress" made me assume that you might be working on it, that's why I wanted to confirm. |
Fully agree with @ihor-sviziev I think its weird that my automated testing which covers the following flakes periodically as new versions of magento are released, seems like it would be trivial enough to set up internally within adobe.
|
|
Hi @hostep , Verified the issue in 2.4-develop instance and the issue is not reproducible,Kindly recheck the behaviour in 2.4-develop Step to reproduce: Kindly refer the below screenshots: Setup install command ran successfully for Both new data base and existing database. |
engcom-Dash
added
the
Issue: needs update
m2-community-project
bot
moved this from Pull Request In Progress
to Dev In Progress
in High Priority Backlog
m2-community-project
bot
added
Progress: dev in progress
and removed
Progress: PR in progress
labels
|
@engcom-Dash: it's definitely reproducible on You just took the wrong steps to reproduce somehow. So here we go again:
It's not needed to start from an empty database, it can be full or empty, doesn't matter. (Also, I would strongly advise you not to post screenshots where you clearly see the database password you are using, it might be a security risk if that server is approachable over the internet) |
|
In our cases we see this as part of the process of running the integration tests, this is because the integration tests need to run I've distilled what we do into this (super hacky) script that reproduces the issue. When I set When I set Reproduction script and usageIt's not a great script but it does repro for me. Using
This script will create a #!/bin/bash
COMPOSER_REPOSITORY=https://repo.packagist.com/your_org_here/
MYSQL_HOST='127.0.0.1'
MYSQL_PORT='24012'
MYSQL_TEST_HOST_FULL="$MYSQL_HOST:$MYSQL_PORT"
MAGE_VERSION='2.4.6-p2'
DIR_BASE="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
set -E
err_report() {
trap - ERR
echo "Error on line $1"
exit 1;
}
trap 'err_report $LINENO' ERR
cd $DIR_BASE
function deps() {
echo "verify dependencies - start"
# verify elastic is available
curl http://0.0.0.0:9200
# verify php 8.2
php --version | grep 8.2
# verify mysql
mysql -uroot -h$MYSQL_HOST --port=$MYSQL_PORT -e 'select 1'
echo "verify dependencies - end"
}
function install_magento() {
echo "install_magento - start"
rm -rf ./broken-magento-install
composer create-project --repository="$COMPOSER_REPOSITORY" magento/project-community-edition:"$MAGE_VERSION" ./broken-magento-install --no-install --no-plugins
cd broken-magento-install
#composer require n98/magerun2:"*" --dev --no-interaction --no-update
composer config --unset repo.0
composer config repo.composerrepository composer "$COMPOSER_REPOSITORY"
#composer config repositories.packagist.org false
#cat composer.json
composer install
php bin/magento module:enable --all
echo "install_magento - end"
}
function setup_integration_tests() {
echo "setup_integration_tests - start"
cd $DIR_BASE/broken-magento-install
printf "<?php\n" > dev/tests/integration/etc/install-config-mysql.php
printf "return [\n" >> dev/tests/integration/etc/install-config-mysql.php
printf " 'search-engine' => 'elasticsearch7',\n" >> dev/tests/integration/etc/install-config-mysql.php
printf " 'elasticsearch-host' => 'localhost',\n" >> dev/tests/integration/etc/install-config-mysql.php
printf " 'elasticsearch-port' => 9200,\n" >> dev/tests/integration/etc/install-config-mysql.php
printf " 'db-host' => '$MYSQL_TEST_HOST_FULL',\n" >> dev/tests/integration/etc/install-config-mysql.php
printf " 'db-user' => 'root',\n" >> dev/tests/integration/etc/install-config-mysql.php
printf " 'db-password' => '',\n" >> dev/tests/integration/etc/install-config-mysql.php
printf " 'db-name' => 'magento_integration_tests',\n" >> dev/tests/integration/etc/install-config-mysql.php
printf " 'db-prefix' => 'trv_',\n" >> dev/tests/integration/etc/install-config-mysql.php
printf " 'backend-frontname' => 'backend',\n" >> dev/tests/integration/etc/install-config-mysql.php
printf " 'admin-user' => \Magento\TestFramework\Bootstrap::ADMIN_NAME,\n" >> dev/tests/integration/etc/install-config-mysql.php
printf " 'admin-password' => \Magento\TestFramework\Bootstrap::ADMIN_PASSWORD,\n" >> dev/tests/integration/etc/install-config-mysql.php
printf " 'admin-email' => \Magento\TestFramework\Bootstrap::ADMIN_EMAIL,\n" >> dev/tests/integration/etc/install-config-mysql.php
printf " 'admin-firstname' => \Magento\TestFramework\Bootstrap::ADMIN_FIRSTNAME,\n" >> dev/tests/integration/etc/install-config-mysql.php
printf " 'admin-lastname' => \Magento\TestFramework\Bootstrap::ADMIN_LASTNAME,\n" >> dev/tests/integration/etc/install-config-mysql.php
printf "];\n" >> dev/tests/integration/etc/install-config-mysql.php
php -l dev/tests/integration/etc/install-config-mysql.php
rm -rf dev/tests/integration/tmp/sandbox-*;
rm -rf generated/code;
mysql -uroot -h$MYSQL_HOST --port=$MYSQL_PORT -e 'drop database if exists magento_integration_tests; create database magento_integration_tests'
mysql -uroot -h$MYSQL_HOST --port=$MYSQL_PORT magento_integration_tests -e 'show databases' | grep magento
test -f app/etc/config.php
rm -rf var/cache;
php bin/magento setup:di:compile
rm -rf var/cache;
echo "setup_integration_tests - end"
}
function run_integration_tests() {
echo "run_integration_tests - start"
cd $DIR_BASE/broken-magento-install
ls -l app/etc/*.php
set -v
vendor/bin/phpunit -c $(pwd)/dev/tests/integration/phpunit.xml.dist --filter MarkAsReadTest -vvv --debug
set +v
echo "run_integration_tests - end"
}
deps;
install_magento;
setup_integration_tests;
run_integration_tests; |
|
@hostep @convenient Internal team is already working on the issue. |
Workaround for magento/magento2#37805 (comment)
m2-community-project
bot
moved this from Ready for Development
to Pull Request In Progress
in High Priority Backlog
m2-community-project
bot
moved this from Pull Request In Progress
to Done
in High Priority Backlog
|
@alzota: please don't close issues without leaving feedback about which commit(s) fixed it. Can you provide these? Thanks! |
m2-community-project
bot
removed
Issue: Confirmed
m2-community-project
bot
moved this from Done
to Ready for Development
in High Priority Backlog
|
@hostep fix is implemented, but not merged yet. Will come back with a commit id on this issue once the fix is merged. Thank you! |
|
Reconfirming the issue, as the issue is already confirmed but moved wrongly in this bucket. |
engcom-Hotel
added
Issue: Confirmed
|
❌ Cannot export the issue. This GitHub issue is already linked to Jira issue(s): https://jira.corp.adobe.com/browse/AC-9230 |
github-jira-sync-bot
added
Progress: PR in progress
and removed
Progress: ready for dev
labels
m2-community-project
bot
moved this from Ready for Development
to Pull Request In Progress
in High Priority Backlog
m2-community-project
bot
moved this from Ready for Development
to Pull Request In Progress
in High Priority Backlog
|
Possibly fixed by ACP2E-2198: fix scenario where configs are not reloaded? Need to find some time to test it out... |
@hostep indeed that is the fix. |
|
Thanks for confirming @alzota, that means we can close this ticket! |
m2-community-project
bot
moved this from Pull Request In Progress
to Done
in High Priority Backlog
m2-community-project
bot
added
Progress: done
and removed
Progress: PR in progress
labels
|
Today, after trying out the commit mentioned above, I can confirm that it fixes this issue for us. Thanks for the quick solution guys! |
Preconditions and environment
2.4-developSteps to reproduce
app/etc/config.phpapp/etc/env.phpMake sure you empty the current database, it should hold no data or structure (this might be optional, I haven't checked with an existing database)(Update: confirmed that database doesn't need to be emptied)Expected result
Works without issues
Actual result
Getting
Additional information
This problem does not occur with Magento 2.4.6-p1, so this is a regression bug.
Issue is most likely to happen in CI pipelines, to run integration tests, or whatever else needs a database.
This can be solved
app/etc/config.phpbefore runningbin/magento setup:install(but that can lead to other problems)bin/magento setup:installtwice (where you account for the first one to fail, the first execution will generate aenv.phpfile, so the second run can load this config in memory)This bug has something to do with these changes that were added in Magento 2.4.6-p2: ACP2E-1958: avoid reloading configs for each requested key (cc @bubasuma & @o-iegorov)
It has something to do with trying to fetch the configuration for key
dbwhich it doesn't find, because it has only loaded the config fromconfig.phpfile and not from theenv.phpfile. So most likely once the db configuration is written toenv.phpfile, it's not being refreshed in memory and leads to this problem.Release note
No response
Triage and priority
The text was updated successfully, but these errors were encountered: