[HttpKernel] DumpDataCollector: do not flush when a dumper is provided #26675
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ogizanagi
commented
Mar 26, 2018
| @@ -131,6 +131,7 @@ public function dump(Data $data) | |||
|
|
|||
| if ($this->dumper) { | |||
| $this->doDump($data, $name, $file, $line); | |||
| $this->isCollected = true; | |||
There was a problem hiding this comment.
Instead we could tweak https://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.
if we can achieve the same without mutating any state, that may be better?
There was a problem hiding this comment.
if we can achieve the same without mutating any state, that may be better?
nicolas-grekas
approved these changes
Mar 29, 2018
fabpot
approved these changes
Mar 30, 2018
|
Thank you @ogizanagi. |
fabpot
added a commit
that referenced
this pull request
Mar 30, 2018
… 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 <!-- see https://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/A This 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: ```diff diff --git a/src/Controller/BlogController.php b/src/Controller/BlogController.php index 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 ```sh vendor/bin/simple-phpunit --filter=BlogControllerTest::testIndex PHPUnit 6.5.7 by Sebastian Bergmann and contributors. Testing Project Test Suite BlogController.php on line 53: "App\Repository\PostRepository" . 1 / 1 (100%) Time: 3.34 seconds, Memory: 44.25MB OK (1 test, 1 assertion) BlogController.php on line 53: "App\Repository\PostRepository" ``` ### After ```sh vendor/bin/simple-phpunit --filter=BlogControllerTest::testIndex PHPUnit 6.5.7 by Sebastian Bergmann and contributors. Testing Project Test Suite BlogController.php on line 53: "App\Repository\PostRepository" . 1 / 1 (100%) Time: 731 ms, Memory: 28.00MB OK (1 test, 1 assertion) ``` Commits ------- 11a0392 [HttpKernel] DumpDataCollector: do not flush when a dumper is provided
This was referenced Apr 2, 2018
Merged
Merged
Merged
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This explains the 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