Skip to content

Running setup:config:set can crash in certain situations, seems to be bug introduced in Magento 2.4.1 #37409

Closed
@hostep

Description

@hostep

Preconditions and environment

  • Magento version: 2.4.1-2.4.6, also current 2.4-develop is impacted

Steps to reproduce

  1. Setup clean Magento and fully install it
  2. Open the file app/etc/env.php and search for the correct db username in the db/connection/default/username path
  3. Change the app/etc/env.php file and change the db/connection/default/username to a non-existing database user (using wrong-user in example below)
  4. Run bin/magento setup:config:set -n --db-user=xxx (where you replace xxx with the correct database user you found in step 2)
  5. Inspect the app/etc/env.php file afterwards to see if the username got updated correctly

Expected result

$ bin/magento setup:config:set -n --db-user=xxx
We saved default values for these options: amqp-host, amqp-port, amqp-user, amqp-password, amqp-virtualhost, amqp-ssl, amqp-ssl-options, db-ssl-key, db-ssl-cert, db-ssl-ca, db-ssl-verify, allow-parallel-generation.

$ echo $?
0

$ grep 'username' app/etc/env.php
                'username' => 'xxx',

Actual result

$ bin/magento setup:config:set -n --db-user=xxx
We saved default values for these options: amqp-host, amqp-port, amqp-user, amqp-password, amqp-virtualhost, amqp-ssl, amqp-ssl-options, db-ssl-key, db-ssl-cert, db-ssl-ca, db-ssl-verify, allow-parallel-generation.

In Abstract.php line 144:

  SQLSTATE[HY000] [1045] Access denied for user 'wrong-user'@'localhost' (using password: YES)


In Abstract.php line 128:

  SQLSTATE[HY000] [1045] Access denied for user 'wrong-user'@'localhost' (using password: YES)


$ echo $?
255

$ grep 'username' app/etc/env.php
                'username' => 'xxx',

Additional information

We have a certain workflow where we expect to have a wrong db user in the app/etc/env.php file and expect it to be able to change it without errors using bin/magento setup:config:set

This used to work before Magento 2.4.1, but seems to have been broken ever since Magento 2.4.1, which is kind of annoying for us.

It looks like the config change does work in that command, but the updated configuration isn't being reloaded before it tries to do whatever it crashes on a bit later.

Release note

No response

Triage and priority

  • Severity: S0 - Affects critical data or functionality and leaves users without workaround.
  • Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
  • Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
  • Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
  • Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area: FrameworkIssue: ConfirmedGate 3 Passed. Manual verification of the issue completed. Issue is confirmedPriority: P2A defect with this priority could have functionality issues which are not to expectations.Progress: doneReported on 2.4.6Indicates original Magento version for the Issue report.Reproduced on 2.4.xThe issue has been reproduced on latest 2.4-develop branch

    Type

    No type

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions