Bug #38253
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
C'est le ticket #38218 #38128 sur le projet alpes-maritimes.
On a une demande (du 28/11/2019) avec trois statuts qui s'enchaînent les deux premiers ne faisant que des modifications de donnée de traitement suivi d'un saut automatique sur le saut suivant :
<pre>S0 -> Modification donnée de traitement -> Saut vers S1 -> Modification de donnée de traitement -> Saut vers S2</pre>
Là la demande s'est arrêté sans raison sur S1, je ne vois pas de modification du workflow autour de cette date (les logs sur la machine s'arrête au 22 novembre mais il y a d'autres demandes traitées autour). Les données de traitement n'ont pas été modifiées comme elles devraient l'être (alors qu'il y a des modifications déjà dans S0 qui ont donc été exécutées).
Mes logs syslog s'arrêtent au 29 novembre (et journald commence au 5 décembre, i.e. hier par rapport au moment où j'écris ces lignes).
Il n'y aucune trace reçu à ces dates pour cette demande (ni enregistré sur le workflow/formulaire), et donc je pense que ce serait du à des crashs (ou arrêts) du worker mais il faudrait voir pourquoi on a pas au moins le résultat de la première modification des données de traitement[1].
[1]: wcs.workflows.perform_items() a un fonctionnement récursif, si un item change le statut de la demande en cours d'exécution, le parcours des items est arrêté, une évolution est ajoutée et le formdata sauvegardé avant de continuer en exécutant les items du statut suivant; je ne vois pas comment il serait possible de perdre le contenu des champs de traitement dans ce cadre.
PS: en fait même SetBackofficeFieldsWorkflowStatusItem fait un formdata.store() en fin de perform()...
PS2: si jamais il y avait une transaction autour de tout ça mais il me semble que w.c.s. fait de toute façon un @conn.commit()@ à la fin de FormData.store()
On a une demande (du 28/11/2019) avec trois statuts qui s'enchaînent les deux premiers ne faisant que des modifications de donnée de traitement suivi d'un saut automatique sur le saut suivant :
<pre>S0 -> Modification donnée de traitement -> Saut vers S1 -> Modification de donnée de traitement -> Saut vers S2</pre>
Là la demande s'est arrêté sans raison sur S1, je ne vois pas de modification du workflow autour de cette date (les logs sur la machine s'arrête au 22 novembre mais il y a d'autres demandes traitées autour). Les données de traitement n'ont pas été modifiées comme elles devraient l'être (alors qu'il y a des modifications déjà dans S0 qui ont donc été exécutées).
Mes logs syslog s'arrêtent au 29 novembre (et journald commence au 5 décembre, i.e. hier par rapport au moment où j'écris ces lignes).
Il n'y aucune trace reçu à ces dates pour cette demande (ni enregistré sur le workflow/formulaire), et donc je pense que ce serait du à des crashs (ou arrêts) du worker mais il faudrait voir pourquoi on a pas au moins le résultat de la première modification des données de traitement[1].
[1]: wcs.workflows.perform_items() a un fonctionnement récursif, si un item change le statut de la demande en cours d'exécution, le parcours des items est arrêté, une évolution est ajoutée et le formdata sauvegardé avant de continuer en exécutant les items du statut suivant; je ne vois pas comment il serait possible de perdre le contenu des champs de traitement dans ce cadre.
PS: en fait même SetBackofficeFieldsWorkflowStatusItem fait un formdata.store() en fin de perform()...
PS2: si jamais il y avait une transaction autour de tout ça mais il me semble que w.c.s. fait de toute façon un @conn.commit()@ à la fin de FormData.store()