UfAlerts sometimes fail to delete old alerts

[lcharette]

UfAlerts may randomly fail to delete old alerts and show old alerts on top of new ones when a page is loaded. This has been linked to the alerts being stored in session files since those files are read and written too often in rapid succession. This may cause overlapping of multiple read and write operations.

A proposed fix for this would be to move ufAlerts from the session storage to the cache storage.

[lcharette]

I managed to somehow successfully replicate by adding multiple addMessageTranslated in a controller ___construct and refreshing twice.

To fix this, a user cache service would need to be added to the existing cache service so it will be easier to associate alerts to a user. The problem is such a user cache also need to be available for guest (non-logged in) users... So probably a session cache and/or user cache...

[Silic0nS0ldier]

Wouldn't a cache be victim to the same issue?

[lcharette]

Not really. Everything goes down to race condition. Session file is written every time the request is done. Config is written when you modify it.

[lcharette]

This is implemented in 4.1. As discussed with @alexweissman, the session based alertStream will still be default for now, but if this problem surface again, it can be easily changed in the config values.

[ktecho]

I'm experiencing this too. Seems to be fixed by changing to cache.

[lcharette]

At this point we should probably just make cache the default...