Open Time

Hier j’annonçais que j’avais enfin trouvé l’explication de ce bug sournois qui m’emmerde depuis des années.

Pour revenir un peu sur ce comportement étrange, à savoir la persistance de certaines notifications, j’ai finalement pris la décision d’instrumenter le gestionnaire de session de Clearbricks pour comprendre exactement de quoi il retournait.

D’abord, en préambule, il faut savoir que les notifications sont stockées dans les variables de session d’administration, elle-même stockées dans la base de données par Clearbricks.

À chaque affichage de page de l’administration, la session présente dans la base, si elle existe et est valide, est rechargée, ce qui permet de récupérer les éventuelles notifications qui seront affichées ensuite. Pour la démonstration on estimera qu’il y a deux notifications en attente d’affichage, A et B.

En gros quand on clique sur un lien de l’administration :

• A.1 La session si elle existe et valide est chargée depuis la base de données
• A.2 La page est préparée incluant les notifications A et B qui sont au passage supprimées dans la variable de session correspondante
• A.3 La page est ensuite affichée avec les notifications A et B
• A.4 La session est enregistrée dans la base

Il peut arriver, et c’est fréquent sur mon installation, qu’une requête Ajax soit déclenchée pendant ce traitement, avec les étapes suivantes :

• B.1 La session si elle existe et valide est chargée depuis la base de données
• B.2 La requête Ajax est traitée
• B.3 La session est enregistrée dans la base

Quand la gestion des notifications a été codée, il était rare que ce soit le cas, sauf que de plus en plus on a des événements en parallèle et on peut se retrouver avec l’enchaînement suivant :

1. A.1 : les notifications A et B sont récupérées depuis la base de données (traitement principal)
2. A.2 : les notifications sont traitées et supprimées de la variable de session (traitement principal)
3. B.1 : les notifications A et B sont récupérées depuis la base de données (traitement Ajax)
4. A.3 : les notifications A et B sont affichées (traitement principal)
5. A.4 : la session est enregistrée dans la base (traitement principal), sans les notifications donc
6. B.2 : les notifications sont toujours dans la variable de session de la requête Ajax
7. B.3 : la session est enregistrée dans la base (requête Ajax), avec les notifications A et B

Pour résumer, il suffit qu’un événement B.1 survienne avant l’événement A.4 pour qu’on se retrouve avec une variable de session non synchronisée entre les différentes requêtes (principale, Ajax).

Voilà pourquoi, j’ai un peu simplifié parce qu’en réalité les niveaux d’imbrications sont encore plus élevés que ça, on peut se retrouver avec des notifications ayant été affichées et supprimées de la variable de session et pourtant encore présentes dans la base de données.