Bug #4821
IntegrityError lors de la sauvegarde des evenements
0%
Historique
Mis à jour par Serghei Mihai il y a plus de 9 ans
- Statut changé de Nouveau à Rejeté
- Patch proposed mis à Non
Problème très probablement du à un accès concurent: 2 exceptions à un rendez-vous périodiques ont été créées quasi-simultanément.
Je n'arrive pas à réproduire localement.
Je le mets en rejected et je le re-ouvre si le problème re-apparait.
Mis à jour par Benjamin Dauvergne il y a plus de 9 ans
Ça dit quoi dans les logs HTTP à cet instant, y voit-on deux POST ?
Mis à jour par Serghei Mihai il y a plus de 9 ans
Les logs le confirment:
192.168.50.1 - - [09/Jul/2014:11:44:17 +0200] "POST /camsp/agenda/2014-9-1/update-rdv/128709 HTTP/1.0" 302 0 "http://calebasse.aps42.org/camsp/agenda/2014-9-1/" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0" 192.168.50.1 - - [09/Jul/2014:11:44:17 +0200] "POST /camsp/agenda/2014-9-1/update-rdv/128709 HTTP/1.0" 499 0 "http://calebasse.aps42.org/camsp/agenda/2014-9-1/" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0"
Mis à jour par Frédéric Péters il y a plus de 9 ans
Ça serait utile d'avoir dans les logs la réelle IP d'origine (j'imagine qu'ici ce n'est pas le cas).
Je doute toujours de ces bugs "parce que deux personnes ont fait l'action pile au même moment"; de la même manière qu'il y avait des doubles GET parce qu'un bouton "bindé" deux fois, ça ne pourrait pas être le cas pour ces POST ?
Par ailleurs, le statut HTTP est ici 302 sur le premier, mais 499 sur le second (?). (ce serait 500 pour l'internal server error (l'IntegrityError du titre), sur lequel il y aurait eu -1 pour une raison obscure ?).
Mis à jour par Benjamin Dauvergne il y a plus de 9 ans
499 est un code d'erreur spécifique à nginx qui indique que le client a fermé la connexion avant de recevoir la réponse, si la soumission est faite en AJAX je ne vois pas trop comment c'est possible, car si il n'y a pas de code pour faire pour explicitement coupé la dernière requête lancée, les deux devraient se terminer normalement. Par contre si c'est un formulaire classique une double soumission va effectivement coupé la première connexion puisque qu'il n'y a pas d'autre moyen d'interrompre une requête HTTP. Donc première question: le bouton de sauvegarde de la boite de dialogue réalise-t-il une soumission AJAX ou naturelle du formulaire ?