Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.6k
Description
Symfony version(s) affected
7.3.x
Description
Problem
I'm trying to use theserver:dump command to debug some endpoints. While I initially used the CLI, it lacks the ability to open nested objects and inspect them more easily. So using the following command, I dumped it to HTML.
bin/console server:dump --format=html> /app/dump.htmlSymfony Var Dumper Server========================= [OK] Server listening on tcp://127.0.0.1:9912 // Quit the server with CONTROL-C.Important
This above command is run inside a PHP-FPM 8.4.10 docker container (with Apache web server and Traefik reverse proxy; no caching on Apache, Traefik or Symfony kernel).
The outputted HTML shows the following.
While the request are made to different controllers (and different URLs) at different times, it only shows the first section URL, controller and datetime.
Debug
While debugging, I found this is due thedata-dedup-id attribute in the generated HTML, which gets hidden with javascript by thehtmlDescriptor.js when it was already present, therefore hiding the<header> with classhidden on it. (so it's not visible in the screenshot above but the information is present in the HTML, it's just hidden).
The problem is that thedata-dedup-id is the same. When inspecting theHtmlDescriptor (andCliDescriptor), it shows using$request['identifier'], that it retrieves from theRequestContextProvider. Theidentifier is set tospl_object_hash($request), which apparently is the same regardless of the new requests.
How to reproduce
config/packages/debug.yaml
when@dev:debug:# Forwards VarDumper Data clones to a centralized server allowing to inspect dumps on CLI or in your browser.# See the "server:dump" command to start a new server.dump_destination:"tcp://%env(VAR_DUMPER_SERVER)%"
cli
The CLI also misses the URL information for new/different requests (most likeley also due to sameidentifier).
Symfony Var Dumper Server========================= [OK] Server listening on tcp://127.0.0.1:9912 // Quit the server with CONTROL-C.GET https://example.local/search-------------------------------------- ------------ ------------------------------------------------ date Tue, 15 Jul 2025 21:49:34 +0200 controller "App\Controller\SearchController::index" source SearchController.php on line 31 file src/Controller/SearchController.php ------------ ------------------------------------------------"hello" ------------ ----------------------------------------- date Tue, 15 Jul 2025 21:49:38 +0200 controller "App\Controller\IndexController::index" source IndexController.php on line 27 file src/Controller/IndexController.php ------------ -----------------------------------------"world" ------------ ------------------------------------------------ date Tue, 15 Jul 2025 21:49:40 +0200 controller "App\Controller\SearchController::index" source SearchController.php on line 31 file src/Controller/SearchController.php ------------ ------------------------------------------------"hello" ------------ ----------------------------------------- date Tue, 15 Jul 2025 21:49:41 +0200 controller "App\Controller\IndexController::index" source IndexController.php on line 27 file src/Controller/IndexController.php ------------ -----------------------------------------"world" ------------ ------------------------------------------------ date Tue, 15 Jul 2025 21:49:43 +0200 controller "App\Controller\SearchController::index" source SearchController.php on line 31 file src/Controller/SearchController.php ------------ ------------------------------------------------"hello"dump.html
Possible Solution
Maybe hash/md5 combining e.g. uri, method, query and request parameters, instead ofspl_object_hash?
Additional Context
I initially thought this might be a feature request, but after looking at blog post"VarDumper server", it shows a screenshot where it dumps with the expected behavior as it was in4.1.