[Issue] Let background commands actually run in the background #38359
Labels
Area: Framework
Issue: Confirmed
Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed
Priority: P2
A defect with this priority could have functionality issues which are not to expectations.
Progress: done
Reproduced on 2.4.x
The issue has been reproduced on latest 2.4-develop branch
This issue is automatically created based on existing pull request: #37511: Let background commands actually run in the background
Update 2023-05-30
After discussion with @engcom-Charlie (thanks!), I set up the Magento Functional Testing Framework locally to investigate the specifics of this test. The report was that the test worked fine on the
2.4-develop
branch, but was failing on #32690, so it was suggested that the changes there were breaking this test, and that the test was fine as-is on2.4-develop
. I thought this was a race condition, but it seems it's more complicated than a simple race condition.The reason the test isn't failing on
2.4-develop
is because STDERR isn't being redirected for the child processes, so the testing framework wasn't actually generating background processes when it should have been. 7d56fe4 fixes that bug, which will mean that all other unreliable tests will now be failing here. Many of the test failures here will be fixed by magento/magento2-functional-testing-framework#904Description
While working on #32690 (comment), it was discovered that the test
StorefrontVerifyProductAfterPartialReindexOnSeveralWebsitesTest
(fromMagento\AcceptanceTest\_default\Backend\StorefrontVerifyProductAfterPartialReindexOnSeveralWebsitesTest
) is unreliable. This pull request aims to improve the reliability of this test. While this is not a complete fix, it will improve the reliability.Why is the test unreliable?
The test aims to ensure that indexers are correctly triggered / rebuilt when making changes in the admin. The general process goes: log into admin, make a change, run cron, witness result. It's the "run cron" step that is causing issues. The internals of that step spawns separate processes, and then returns. These separate processes will run in the background and will work, however there is a race condition between these background processes running to completion and the next step of the test being carried out. When the indexer process is quick, all is well. When the test framework gets to the next step before the background process complete, the test fails.
How does this change help?
This pull request turns the background process into a foreground process, so the test framework won't ever reach the next step until the "background" process finishes.
Why is this change incomplete?
There is no guarantee that a job has actually been scheduled. There is still an expectation that there is a
indexer_update_all_views
job in the queue, ready to be executed. Usually this will be the case, however it's not guaranteed. Further test improvements are welcome in this area.Manual testing scenarios
Run the following PHP script. It should report success.
Contribution checklist
The text was updated successfully, but these errors were encountered: