on fait un +1 côté redis et ça timeout (avant que l'incrément SQL)
on retente un +1 côté redis, mais ça ne change rien vu que ce compte a déjà noté ce commentaire. Et on arrête ici (encore avant l'incrément SQL) -> on est donc à +5 redis / +4 SQL
on rajoute encore un +1 / +1
on finit donc à +6 redis et +5 SQL, ce qui donne bien « Évalué à 7 (+6/-0). »
on finit donc à +2 redis et +2 SQL, ce qui donne bien « Évalué à 5 (+2/-0). »
Bref faut une transaction si on veut éviter ça (ce qui est vrai partout où on utilise un peu de redis et un peu de SQL). Nb: la situation est même encore plus fourbe car on doit stocker la note côté redis, puis incrémenter/décrémenter côté sql, puis décrémenter le nb de notes du compte notant, et c'est l'ensemble qui devrait être transactionnel si on veut éviter une erreur de 1 tous les vraiment pas souvent et le risque rare d'offrir une note gratuite.
[^] # Re: Étrange
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi Note commentaire. Évalué à 3 (+0/-0). Dernière modification le 31 janvier 2026 à 19:38.
Le cas évoqué initialement dans ce ticket :
Dans le second cas https://linuxfr.org/nodes/140975/comments/200561
Dans le troisième cas https://linuxfr.org/nodes/141676/comments/2010504
Bref faut une transaction si on veut éviter ça (ce qui est vrai partout où on utilise un peu de redis et un peu de SQL). Nb: la situation est même encore plus fourbe car on doit stocker la note côté redis, puis incrémenter/décrémenter côté sql, puis décrémenter le nb de notes du compte notant, et c'est l'ensemble qui devrait être transactionnel si on veut éviter une erreur de 1 tous les vraiment pas souvent et le risque rare d'offrir une note gratuite.