Magento2: Page messages accumulate and are not cleared

[thdoan]

Steps to reproduce

1. Install Magento from develop branch.
2. Do something to generate a page message (in my case, I generated several Wish List success/error messages).

3. Reload the page or go to another page.

   Expected result

4. The page messages should be cleared upon navigating to another page or reloading the current page.

   Actual result

5. The page messages reappear, and now you can't get rid of them. In the example below, the messages were originally generated on the product and wishlist pages, but now they appear on every page and won't go away.

Furthermore, as you can see in the screenshot, some messages are duplicated.

UPDATE: I was finally able to clear the page messages by disabling multiple wish lists in Admin.

[andimov]

@thdoan
Thank you for reporting!
Do you use varnish?

[thdoan]

@andimov No, right now I'm using default settings in developer mode with all caches disabled in Luma theme.

[Nehace40]

@andimov is there any update about this?

[andimov]

@Nehace40
In the near future, one of our team will reproduce it and will create an internal ticket to fix it.

[thdoan]

In the meantime we ended up creating our own in-house messaging system and disabling the built-in one. It would be great to see this fixed so we can revert back to stock messaging.

[jlnelson]

I ended up seeing this same bug show up when submitting reviews for products. I created a small writeup for it:

Issue was tracked down to vendor/magento/module-customer/view/frontend/web/js/customer-data.js. All line numbers I use will refer to the customer-data.js file in Magento 2.0.7.

Good case timeline

1. Review submit button is clicked.
2. Request made to server to save review.
3. Callback on line 230 is triggered, invalidating 'messages' by placing 'messages': true in local storage under 'mage-cache-storage-section-invalidation'.
4. Page reload triggers.
5. getFromServer (line 44) is called to load 'messages' section because it was invalidated creating a GET request for sections.
6. GET request for vendor/module-theme/view/frontend/web/js/view/messages.js.
7. messages.js from step 6 is recieved.
8. messages.js calls extend with {disposableCustomerData: 'messages'}
9. The extender defined on line 55 is called which defines callback to be fired when target changes. Target is currently empty object.
10. Data for GET request from step 5 is received updating target object from step 9 with new messages.
11. Callback from step 9 is called due to change in target and setTimeout on line 58 is called.
12. 3 seconds later, line 59, the 'messages' section is removed from localStorage.

Bad case timeline

1. Review submit button is clicked.
2. Request made to server to save review.
3. Callback on line 230 is triggered, invalidating 'messages' by placing 'messages': true in local storage under 'mage-cache-storage-section-invalidation'.
4. Page reload triggers.
5. getFromServer (line 44) is called to load 'messages' section because it was invalidated creating a GET request for sections.
6. GET request for vendor/module-theme/view/frontend/web/js/view/messages.js.
7. Data for GET request from step 5 is received updating 'messages' section.
8. messages.js from step 6 is recieved.
9. messages.js calls extend with {disposableCustomerData: 'messages'}
10. The extender defined on line 55 is called which defines callback to be fired when target changes. Target includes current messages.

The main difference between good case and bad case is the order of when messages.js is loaded in relation to the completion of the sections GET request. In good case, messages.js is loaded before sections are received. This allows the subscribe on line 57 to fire when sections data is received. In the bad case the subscribe doesn't happen until after we already have data, which means the subscribe callback never fires because the data will never change. It changed BEFORE we subscribed in the bad case. Because of this, the 'messages' section is never removed from localStorage which means it will appear on every page as the user navigates through the site.

[magento-engcom-team]

@thdoan, thank you for your report.
The issue is already fixed in develop branch, 2.2.0, 2.1.9

[mbrzuzy]

@magento-engcom-team I'm on v2.1.10 and it's still happening.

[dangnguyenak]

@magento-engcom-team I'm on 2.2.1 and its still happening

[SamB-GB]

@magento-engcom-team I am still seeing this on 2.2.3 as well

[patrickoliveras]

I'm getting this as well on 2.1.9

[AlexandreKhayrullin]

Still happens on a 2.3.0.

[rommelfreddy]

Magento Community v2.3.1

i have a similar problem - not related to the wishlist.
a lot of messages from all over the site will appear on any site. sometimes some messages does disappear - a few page later they appear again ... very confusing ...