Bug #67454
ForeignKeyViolation: ERREUR: une instruction insert ou update sur la table « transient_data » viole la contrainte de clé
0%
Description
https://sentry.entrouvert.org/entrouvert/nfrance/issues/62567/
ForeignKeyViolation: ERREUR: une instruction insert ou update sur la table « transient_data » viole la contrainte de clé
étrangère « transient_data_session_id_fkey »
DETAIL: La clé (session_id)=(Hyd1B_ZwHA67DYqCNyBr2Q) n'est pas présente dans la table « sessions ».
(5 additional frame(s) were not displayed)
...
File "wcs/qommon/sessions.py", line 398, in __setitem__
session.store()
File "wcs/sql.py", line 617, in f
return func(*args, **kwargs)
File "wcs/sql.py", line 3424, in store
v.store()
File "wcs/sql.py", line 617, in f
return func(*args, **kwargs)
File "wcs/sql.py", line 3372, in store
cur.execute(sql_statement, sql_dict)
Fichiers
Révisions associées
Historique
Mis à jour par Lauréline Guérin il y a presque 2 ans
- Fichier 0001-sql-do-not-fail-on-transient_data-store-if-session-i.patch 0001-sql-do-not-fail-on-transient_data-store-if-session-i.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Assigné à mis à Lauréline Guérin
- Patch proposed changé de Non à Oui
J'aurais bien aimé enchaîner deux ON CONFLICT dans l'instruction sql, mais ça n'a pas l'air permis.
Alors try/except :/
Mis à jour par A. Berriot il y a presque 2 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par A. Berriot il y a presque 2 ans
(vu que ça a l'air d'être un edge case, ça me parait pas gravissime de gérer ça côté python avec un try/except plutôt que dans le SQL)
Mis à jour par Lauréline Guérin il y a presque 2 ans
- Statut changé de Solution validée à En cours
A reprendre avec IntegrityError pour être plus souple ? https://sentry.entrouvert.org/entrouvert/publik/issues/62630/
Mis à jour par Benjamin Dauvergne il y a presque 2 ans
Je pense que le souci c'est les conn.commit() dans TransientData.store() sans ça la sauvegarde de la session se passerait dans une seule transaction, celle en cours quand Session.store() commence, là on se retrouve avec pleins de bouts de transactions et entre temps la session qui disparaît, au passage déplacer la sauvegarde des TransientData à la fin de Session.store(), le UPDATE/INSERT de la session va verrouiller la session.
J'ajouterai un paramètre commit=True à False dans Session.store().
Aussi on ne devrait pas automatiquement basculer de UPDATE vers INSERT, si la session n'est plus là alors qu'on a son id c'est qu'elle a été supprimée, il ne faut pas la ressusciter (si l'id est automatiquement généré par quixote et qu'on ne peut donc pas baser la logique sur sa présence, prévoir un flag session nouvelle/session chargée). Le code de Django est mieux réfléchi qu'ici. Ça donnera les erreurs qu'on voit coté Django de session qui ont disparu pendant le traitement d'une requête mais on pourra les traiter plus proprement que Django qui en fait tout une histoire.
Mis à jour par Lauréline Guérin il y a plus d'un an
- Fichier 0001-sql-do-not-fail-on-transient_data-store-if-session-i.patch 0001-sql-do-not-fail-on-transient_data-store-if-session-i.patch ajouté
- Statut changé de En cours à Solution proposée
Le même patch avec IntegrityError
Je n'ose pas me lancer dans le chantier décrit par Benjamin.
Mis à jour par Frédéric Péters il y a plus d'un an
- Statut changé de Solution proposée à Solution validée
Oui très bien comme ça. (tu peux pousser dès jenkins ok, je comptais pousser #67843 et tagguer une nouvelle version).
Mis à jour par Lauréline Guérin il y a plus d'un an
- Statut changé de Solution validée à Résolu (à déployer)
commit 5f40d72c87f69ded10360418f952eb54604e8ad9
Author: Lauréline Guérin <zebuline@entrouvert.com>
Date: Mon Jul 25 10:58:11 2022 +0200
sql: do not fail on transient_data store if session is not found (#67454)
Mis à jour par Transition automatique il y a plus d'un an
- Statut changé de Résolu (à déployer) à Solution déployée
sql: do not fail on transient_data store if session is not found (#67454)