Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[HttpKernel] DumpDataCollector: do not flush when a dumper is provided#26675
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
[HttpKernel] DumpDataCollector: do not flush when a dumper is provided#26675
Uh oh!
There was an error while loading.Please reload this page.
Conversation
| if ($this->dumper) { | ||
| $this->doDump($data,$name,$file,$line); | ||
| $this->isCollected =true; |
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.
Instead we could tweakhttps://github.com/symfony/symfony/pull/26675/files#diff-b043f95afd7daa1be0bdd864620c510dR70 to check if$this->dumper is set. But I find it more expressive as is. Let me know.
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.
if we can achieve the same without mutating any state, that may be better?
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.
if we can achieve the same without mutating any state, that may be better?
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.
Alright
fabpot commentedMar 30, 2018
Thank you@ogizanagi. |
… is provided (ogizanagi)This PR was merged into the 2.7 branch.Discussion----------[HttpKernel] DumpDataCollector: do not flush when a dumper is provided| Q | A| ------------- | ---| Branch? | 2.7 <!-- see below -->| Bug fix? | yes| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->| BC breaks? | no <!-- seehttps://symfony.com/bc -->| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->| Tests pass? | yes <!-- please add some, will be required by reviewers -->| Fixed tickets |https://github.com/ogizanagi/symfony/blob/3db14045d41eecf78e3557c2d64f28fe27ed3a66/src/Symfony/Component/HttpKernel/DataCollector/DumpDataCollector.php#L208-L209 <!-- #-prefixed issue number(s), if any -->| License | MIT| Doc PR | N/AThis explains [the workaround I initially used](https://github.com/ogizanagi/symfony/blob/3db14045d41eecf78e3557c2d64f28fe27ed3a66/src/Symfony/Component/HttpKernel/DataCollector/DumpDataCollector.php#L208-L209) in the server dumper PR original code.I might be wrong on the intent, but as soon as a dumper is provided (e.g by setting `debug.dump_destination: php://stderr`), I think there is no need to set the `DumpDataCollector::$isCollected` flag to `false` as we explicitly ask for the dump to be output directly somewhere. So ne need to output again on `__destruct`.Spotted by running tests on the `symfony/demo` with the server dumper enabled: dumps were output twice. Once on the server, once at the end of the tests.But this can be easily seen as well by using `debug.dump_destination: php://stderr` on `test` env:```diffdiff --git a/src/Controller/BlogController.php b/src/Controller/BlogController.phpindex e3e30aa..bf9744e 100644--- a/src/Controller/BlogController.php+++ b/src/Controller/BlogController.php@@ -50,6 +50,7 @@ class BlogController extends AbstractController */ public function index(int $page, string $_format, PostRepository $posts): Response {+ dump(get_class($posts)); $latestPosts = $posts->findLatest($page); // Every template name also has two extensions that specify the format and```### Before```shvendor/bin/simple-phpunit --filter=BlogControllerTest::testIndexPHPUnit 6.5.7 by Sebastian Bergmann and contributors.Testing Project Test SuiteBlogController.php on line 53:"App\Repository\PostRepository". 1 / 1 (100%)Time: 3.34 seconds, Memory: 44.25MBOK (1 test, 1 assertion)BlogController.php on line 53:"App\Repository\PostRepository"```### After```shvendor/bin/simple-phpunit --filter=BlogControllerTest::testIndexPHPUnit 6.5.7 by Sebastian Bergmann and contributors.Testing Project Test SuiteBlogController.php on line 53:"App\Repository\PostRepository". 1 / 1 (100%)Time: 731 ms, Memory: 28.00MBOK (1 test, 1 assertion)```Commits-------11a0392 [HttpKernel] DumpDataCollector: do not flush when a dumper is provided
Uh oh!
There was an error while loading.Please reload this page.
This explainsthe workaround I initially used in the server dumper PR original code.
I might be wrong on the intent, but as soon as a dumper is provided (e.g by setting
debug.dump_destination: php://stderr), I think there is no need to set theDumpDataCollector::$isCollectedflag tofalseas we explicitly ask for the dump to be output directly somewhere. So ne need to output again on__destruct.Spotted by running tests on the
symfony/demowith the server dumper enabled: dumps were output twice. Once on the server, once at the end of the tests.But this can be easily seen as well by using
debug.dump_destination: php://stderrontestenv:Before
After