In the symfony docs, both can be find:
What it the symfony best practise?

• {% if app.request.hasPreviousSession %}
• {% if app.session.started %}

https://symfony.com/blog/new-in-symfony-3-3-improved-flash-messages Normally symfony should do it automatically or?

@sebastianblum I think your question is more for @javiereguiluz or maybe rather @nicolas-grekas.

I just picked this from the doc, as part of my talk Take your Http caching to the next level with xkey & Fastly at Symfony Live London, and symfony-demo just happens to follow what ever doc says is best practice.

But that said I agree, the framework should not trigger session start on things like this, if it can avoid it.

The area where flash messages are displayed is by nature not cacheable, as its content can vary per user. Having no flash messages doesn't mean the page is cacheable: caching it would mean that the empty-state can be cached - which would mean that flash messages could be hidden to users that should see them (since the cached version would be served.)

The only way I can think of to fix this once for all is by using a separate request for flash messages (i.e. either XHR or IFRAME or ESI).

The only way I can think of to fix this once for all is by using a separate request for flash messages (i.e. either XHR or IFRAME or ESI).

True, that would probably be cleaner then how FosHttpCache works around this:
https://foshttpcachebundle.readthedocs.io/en/latest/features/helpers/flash-message.html

Let's display flashes only when the verb is POST!

Thank you André.

@javiereguiluz sorry but this is wrong as explained...

It looks correct according to Symfony Docs 😕 Please, someone send a new pull request to fix this merge.

But please keep in mind that this is the Symfony Demo app ... so we cant't complicate it with things that are only relevant for apps with lots of traffic. For example we can't display the flashes with a sub-request and enable Varnish, etc. Thanks!

Sure, but docs should probably be updated here, and demo should follow best practice in docs right?
In other words imho this merge is correct as long as doc is like it is :P

I'd like to make a new release of this app very soon. If someone shows me how to fix this merge, I can make the new PR myself. Thanks!

replace if app.request.hasPreviousSession by if app.request.method == 'POST' yes

Thanks Nico! See #863.

@nicolas-grekas the use case of flash messages is precisely to display a message on a GET request after the redirection returned by the POST request. Displaying them only for POST requests make them useless (if you render some content instead of redirecting, you don't need to use the flash message system, as you can pass a variable to your template without storing it in the session)

Sure, I forgot about the redirect. This means there are conflicting expectations here: you cannot cache a page and use the session at the same, even conditionally.
Using JavaScript, we can fix the issue but we need to completely redesign how flashes work:
Instead of making the POST request trigger a 302, we would make it a 200 with a meta redirection. Just before the meta tag, we would dump a script one that would put the flashes in local storage. Then the header of all pages would contain JS to read that and display them.