Added max_tries WebProfiler configuration property #15670
Conversation
|
|
||
| public function __construct(\Twig_Environment $twig, $interceptRedirects = false, $mode = self::ENABLED, $position = 'bottom', UrlGeneratorInterface $urlGenerator = null, $excludedAjaxPaths = '^/bundles|^/_wdt') | ||
| public function __construct(\Twig_Environment $twig, $interceptRedirects = false, $mode = self::ENABLED, $position = 'bottom', $maxTries = 3, UrlGeneratorInterface $urlGenerator = null, $excludedAjaxPaths = '^/bundles|^/_wdt') |
There was a problem hiding this comment.
Here, the default value of maxTries is 3, but in the rest of the code is 5.
There was a problem hiding this comment.
Thanks for notice, already fixed
|
@kptLucek I'd like to ask you what is the rationale behind this change, because I don't understand why this option is needed. Thanks! |
|
|
||
| public function __construct(\Twig_Environment $twig, $interceptRedirects = false, $mode = self::ENABLED, $position = 'bottom', UrlGeneratorInterface $urlGenerator = null, $excludedAjaxPaths = '^/bundles|^/_wdt') | ||
| public function __construct(\Twig_Environment $twig, $interceptRedirects = false, $mode = self::ENABLED, $position = 'bottom', $maxTries = 5, UrlGeneratorInterface $urlGenerator = null, $excludedAjaxPaths = '^/bundles|^/_wdt') |
There was a problem hiding this comment.
You're right! My miss, thanks for notice.
|
@javiereguiluz you were pretty fast tho, were typing why such change were made in time when recived your's comment. As described - sometimes profiler couldn't store data in defined 5 tries, that's why i had to override template manually in app directory to make this works, sometimes it does take ~10-15 attempts to recive working toolbar. |
|
Anyone knows why can the profiler fail and why could it fail more than 5 times but less than 10 (as in @kptLucek case)? |
|
We have always been against adding settings for no good reasons. If we need to increase from 5 to 15, let's do that, but making it configurable does not make sense as people won't know why/when to change this value. Another possibility would be to find another way to deal with this problem (ping @tucksaun). |
|
Situation described here is happening to me mostly, when in template which is being rendered are too many render(controller()) (varnish on prod so doesn't really matter). Whole cache is being build in ~3-5 min, usual response time is around 3-10s (container's weight is more than 10mb). I think (as described above) that problem is somewhere in between storing - reading profiler's data, after request is completed, they're still being written which means that they're not accesible yet |
|
The problem happens when there is a lot happening during the |
|
I like the idea of showing a loading indicator explaining the situation. A quick mockup:
|
|
Well, idea is good, but how would you describe when this loading should end? I mean, how many attempts and then "enough" of trying? Or maybe an infinite loop? |
|
@kptLucek infinite loop and ideally a link to abort it, as Fabien said. |
|
I'll take care about this one then |
|
Abort is needed as the spinner will never end if the profile is not stored for any reasons. |
|
@kptLucek I'm closing this PR as it cannot be merged. I will let you open a new one with the other approach as discussed here. Thanks. |
This property were required in project im working on, due to really long load time - profiler couldn't store data in defined 5 tries.