Persisted deprecation logs seems inconsistent

[ro0NL]

Q	A
Bug report?	yes
Feature request?	no
BC Break report?	no
RFC?	no
Symfony version	3.x

Given https://symfony.com/blog/new-in-symfony-3-3-persisted-deprecation-logs

Without further investigating any inner details on this; i did a fresh install of symfony-standard, and the logs still seem to be very inconsistent.

Steps roughly taken;

$ git clone symfony-standard...
$ composer install
$ git pull vendor/symfony/symfony
$ rm -rf var/cache/* && rm -rf var/logs/* && bin/console cache:clear --no-warmup

User Deprecated: The Twig_TokenParser_Include class is considered final. It may change without further notice as of its next major version. You should not extend it from Twig_TokenParser_Embed.

but sometimes it is;

User Deprecated: The Symfony\Bundle\FrameworkBundle\EventListener\SessionListener class is deprecated since version 3.3 and will be removed in 4.0. Use Symfony\Component\HttpKernel\EventListener\SessionListener instead.

and sometimes;

User Deprecated: The Symfony\Bundle\FrameworkBundle\EventListener\SessionListener class is deprecated since version 3.3 and will be removed in 4.0. Use Symfony\Component\HttpKernel\EventListener\SessionListener instead.

User Deprecated: The Symfony\Component\HttpKernel\EventListener\SessionListener class is considered final since version 3.3. It may change without further notice as of its next major version. You should not extend it from Symfony\Bundle\FrameworkBundle\EventListener\SessionListener.

User Deprecated: The Twig_TokenParser_Include class is considered final. It may change without further notice as of its next major version. You should not extend it from Twig_TokenParser_Embed.

but then.. sometimes (mostly 2nd refresh);

User Deprecated: The Symfony\Bundle\FrameworkBundle\EventListener\SessionListener class is deprecated since version 3.3 and will be removed in 4.0. Use Symfony\Component\HttpKernel\EventListener\SessionListener instead.

User Deprecated: The "Twig_TokenParser_Include" class is considered final. It may change without further notice as of its next major version. You should not extend it from "Twig_TokenParser_Embed".

It looks related to composer install, running that in between increases the logs.

¯_(ツ)_/¯

[stof]

for the Twig_TokenParser_Include, it looks like a mistake in Twig itself (tagging a class as @final while Twig itself relies on extending it)

[nicolas-grekas]

The new panel is only about deprecations triggered while compiling the container.
Other "run-once" logic are triggered at their own moment, and cannot be tracked easily (eg Twig compiling a template can happen at anytime).
So this cannot be fixed generally, but only on a case by case basis.
One place that have predictable run-once logic is the cache warmer. We may persist deprecation triggered there.

But as far as this issue is concerned, I'd close it as "too vague", as explained :)

[stof]

@nicolas-grekas we should still ensure that new projects don't trigger any deprecation though.

[ro0NL]

Ok.. maybe im missing it. But the following scenario confuses me;

• fresh install symfony-standard -> git pull symfony/symfony
• composer install -> cache is warm now
• open private browser -> 3 deprecations
• soft refresh -> 1 deprecation

So im losing 2 deprecations here.. which i expected to be persisted from the 1st run. Ie. i can imagine the number increases... but decreasing?

[stof]

@ro0NL the first run may contain the persisted compilation deprecation, but also deprecations coming from the cache warming running after that (and which are not persisted currently)

[ro0NL]

I see.. thanks 👍

another issue (maybe :));

• composer install
• cat var/cache/docker/appDockerDebugProjectContainerDeprecations.log

a:1:{i:0;a:4:{s:4:"type";i:16384;s:7:"message";s:261:"The support of special environment variables that start with SYMFONY__ (such as "SYMFONY__KERNEL__CURRENT_USER") is deprecated as of 3.3 and will be removed in 4.0. Use the %env()% syntax instead to get the value of environment variables in configuration files.";s:4:"file";s:79:"/projects/sf/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Kernel.php";s:4:"line";i:640;}}

• open private browser
• cat var/cache/docker/appDockerDebugProjectContainerDeprecations.log

a:0:{}

The WDT never reported this one..

I guess it's complicated matter.. please close if there's nothing we can do here. But THB i expected more consistency with "persisting logs".

[stof]

looks like the file got replaced somehow

[ScullWM]

@ro0NL as @stof says, the only way to have your *ContainerDeprecations.log updated from one log to zero log, is the (re)build and dump of the container if the previous container wasn't "fresh".

Do you have different value of filemtime on the var/cache/docker/appDockerDebugProjectContainer.php after the "composer install" and the "private browser" request ?

[ro0NL]

Ill have a look at the log file tomorrow at work about whats happening, cant really reproduce it at home due different environment (it works as expected).

Consider this closed after #22546