Prevent Web API functional test installation from dropping an unrelated database (#36291)

[lbajsarowicz]

Description

Running the Web API functional tests with TESTS_MAGENTO_INSTALLATION=enabled drops all tables of the live database instead of the test database configured in dev/tests/api-functional/config/install-config-mysql.php.

Root cause

WebApiApplication::getCustomDirs() returns an empty array, so – unlike the integration tests framework, which installs into its own dev/tests/integration/tmp/sandbox-*/etc – the Web API framework resolves its configuration directory to app/etc of the installation that serves TESTS_BASE_URL.

As a result:

• Application::cleanup() runs bin/magento setup:uninstall with --magento-init-params that carry no directory overrides, so the command bootstraps the deployed app/etc/env.php and drops every table of the database that file points at — the developer's main database, not magento_functional_tests.
• WebApiApplication::install() then runs setup:install, which rewrites that same app/etc/env.php (including the encryption key) to the test database.

Both steps are inherent to the design: the tests send HTTP requests to the installation under TESTS_BASE_URL, so the framework must install in place. What is not acceptable is doing that silently against a database the test configuration never names.

Fix

WebApiApplication::install() now aborts before any destructive command when the database in TESTS_INSTALL_CONFIG_FILE differs from the database of the already installed application, with a message naming both databases and the two ways forward (align the install config, or set TESTS_MAGENTO_INSTALLATION to disabled).

When the two databases match — the case in CI and in a correctly configured local setup — nothing changes: setup:uninstall and setup:install run exactly as before.

Fixed Issues (if relevant)

1. Fixes API functional tests drop all tables from main database #36291: API functional tests drop all tables from main database

Manual testing scenarios

Data loss is prevented (mismatching databases)

1. Install Magento into database magento and confirm the tables exist.

2. Copy dev/tests/api-functional/config/install-config-mysql.php.dist to install-config-mysql.php, leaving db-name as magento_functional_tests.

3. Copy phpunit_graphql.xml.dist to phpunit_graphql.xml and set TESTS_MAGENTO_INSTALLATION to enabled (TESTS_CLEANUP stays enabled).

4. Run cd dev/tests/api-functional && ../../../vendor/bin/phpunit -c phpunit_graphql.xml.

5. Before the fix: the bootstrap runs setup:uninstall and all tables of magento are dropped.
   After the fix: the bootstrap fails immediately with

   Web API functional tests are configured to install Magento into the "magento_functional_tests" database, but the installation in "/var/www/html/app/etc" uses the "magento" database. Installing would drop all tables of "magento" and overwrite its deployment configuration, because Web API functional tests reuse the application they send requests to. Either configure the test installation to use the "magento" database, or set TESTS_MAGENTO_INSTALLATION to "disabled" to run the tests against the already installed application.

   and the magento database is untouched (verified: table count unchanged).

No false positive (matching databases)

1. Set db-name in install-config-mysql.php to the database of the installed application.
2. Run the suite again — the bootstrap proceeds and issues setup:uninstall, setup:install, indexer:set-mode realtime and indexer:reindex in the same order as before this change.

Installation disabled (default)

With TESTS_MAGENTO_INSTALLATION=disabled (the shipped default) install() is never called, so the guard is not reached and existing workflows are unaffected.

Questions or comments

The guard compares database names only. Host comparison was deliberately left out to avoid false positives from equivalent spellings (localhost vs 127.0.0.1) that would break existing setups.

No automated test is included: dev/tests/api-functional/framework is not covered by any registered PHPUnit suite (dev/tests/unit/phpunit.xml.dist does not include it, and the framework has no tests/unit harness of its own, unlike dev/tests/integration/framework). Both branches of the guard were verified manually as described above. Happy to add a suite for the Web API framework if maintainers want that scope.

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable) — see "Questions or comments"
• All automated tests passed successfully (all builds are green)

[m2-assistant]

Hi @lbajsarowicz. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[lbajsarowicz]

@magento run all tests