-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FIX #27299 Consecutive Requests in Integration Tests failing #27300
FIX #27299 Consecutive Requests in Integration Tests failing #27300
Conversation
Hi @lbajsarowicz. Thank you for your contribution
For more details, please, review the Magento Contributor Guide documentation. |
@magento run Integration Tests Interesting... no test failures were reported, but build was shown as failing, just restarted |
…etDispatched(false) before each AbstractController::dispatch()
3cbba4e
to
5d0c972
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @lbajsarowicz,
Could you add some tests that checks that actual issue was fixed?
I have this in separate PR but sure, I can copy some of them here. That's actually good idea. |
To make sure that Integration Test works, you can comment out: As a result you'll get:
|
Hi @ihor-sviziev, thank you for the review. |
Hi @lbajsarowicz, thank you for your contribution! |
Description (*)
Consecutive Requests in Integration Tests were failing due to the fact of Requests object being shared between dispatches. I am aware that some developers need to perform the same
dispatch
multiple times with the same object, so I haven't destroyed Request object after dispatch.Under the hood, Magento was skipping Execution, as
isDispatched
wastrue
, so the wholedispatch()
was returningnull
magento2/lib/internal/Magento/Framework/App/FrontController.php
Lines 85 to 116 in 510310b
Instead - I just call
setDispatched(false)
before eachdispatch()
.Additionally, I introduced
resetRequest
method that empties the state of Request.Related Pull Requests
Fixed Issues (if relevant)
dispatch($uri)
on Test AbstractController fails #27299Manual testing scenarios (*)
Described in #27299
Questions or comments
I had no time to investigate why implementing
resetRequest
with destroying old Request object and instantiating new one causes Fatal errors, but the current implementation is also correct.Contribution checklist (*)