Certains tickets ne s'annulent pas avec le message "La tâche active de cette demande a changé. Un autre opérateur a probablement effectué une action entre-temps"

[geoconcept11]

Bonjour,
Chez holdinova, certaines requêtes qui doivent être annulées ne peuvent pas l'être à cause d'un message qui survient alors de la tentative d'envoyer une réponse négative "Annuler".

Cela survient de manière aléatoire.
Si besoin des logs sont disponibles.
Merci.

[daniellappert]

Bon, je tombe aussi sur la chose (en version 2.2). Voici les étapes que j'ai réalisées avant que la chose ne survienne:

1. J'ai activé le connecteur Viageo (il était inactif, parce que j'étais en migration du cadastre).
2. J'ai fait une première demande sur plans-reseaux.ch, qui a fait planter mon extraction FME (probablement parce que j'ai fait une demande en France).
3. J'ai annulé cette première demande.
4. J'ai fait une deuxième demande sur plans-reseaux.ch, pour laquelle l'extraction a parfaitement fonctionné.
5. Sans rien vérifier, j'ai écrit "test" (sans les apostrophes) dans le champs d'annulation, puis j'ai cliqué Annuler. Le message est survenu à ce moment-là.
6. J'ai essayé toutes les possibilités: Annuler, Valider et Relancer. Malheureusement la demande reste dans cet état second.
7. Une reconnexion à Extract ne permet pas de corriger le problème.

[daniellappert]

Exemple entre un cas annulé qui fonctionne et celui qui reste en rade. Ce sont les tables requests et request_history qui sont illustrées ici.

Tables_postgre.xlsx

Ajout de la table tasks, qui semble aussi touchée par le problème. D'ailleurs, pourquoi on ne voit que pour quelques demandes les tâches dans tasks et pas pour toutes les demandes? Y a-t-il une raison particulière?

Donc il y a 3 tables qui ne sont pour une raison quelconque pas synchrones: requests, request_history et tasks.

[daniellappert]

La demande ne peut pas être supprimée dans l'historique! Le message renvoyé est du style (je ne me souviens pas exactement du wording): "fonction impossible. Ressayer plus tard.".

Pour pouvoir résoudre le problème, j'ai fait les chose suivantes:

• Mis STANDBY dans la "Validation opérateur" pour request_history.id_record=7054 (voir fichier Excel).
• Supprimé la dernière ligne avec "delete from request_history r where r.id_record = 7055;".
• Ainsi que la tâche correspondante dans la table tasks: "delete from tasks t where t.id_task = 1628;".
  Cela a débloqué le souci et la demande a été annulée comme prévu...

[benoitregamey]

Suspicion de transactions SQL non atomiques. Semble arriver qu'avec des installations où la base de données tourne sur un serveur différent de l'application. Bug non reproductible...

[AlexandreLuisetRomandeEnergie]

A Romande Energie nous avons le même comportement que décrit par Daniel. Effectivement nous sommes sur des serveurs séparés, dans notre cas il s'agit même d'un extract déployé en container (avec docker et kubernetes) et la PostgreSQL est sur Azure.
J'ai automatisé un contrôle de cohérence pour régler le problème, tous les soirs je viens vérifier la cohérence entre les tables requests et request_history.
Pour donner un ordre de grandeur, sur 6 mois nous avons à peu près 15 demandes bloquées de cette manière. Ce n'est pas réparti uniformément, il y a souvent des périodes d'une à deux semaines où les demandes de plan sont bloquées plus souvent.

[daniellappert]

@AlexandreLuisetRomandeEnergie , tu fais quoi quand un problème d'incohérence survient? Juste histoire que je puisse aussi automatiser la résolution ;-)
@benoitregamey , oui, on a aussi un PostgreSQL sur un autre serveur. Notre environnement est composé d'un serveur Tomcat et Extract, d'un serveur PostgreSQL avec une instance propre à Extract et d'un serveur FME Flow. Toutes les machines tournent sous Windows Server dans le même domaine.

[AlexandreLuisetRomandeEnergie]

@AlexandreLuisetRomandeEnergie , tu fais quoi quand un problème d'incohérence survient? Juste histoire que je puisse aussi automatiser la résolution ;-)

Je lance un workflow tous les soirs après la désactivation de l'extract (il faut éviter que quelqu'un fasse des validations). Le but c'est de revenir en arrière et revenir sur l'étape de validation pour les commandes bloquées. Car cette erreur n'arrive qu'après une étape de validation. On lit les tables requests et request_history, on fait une jointure pour rassembler les informations sur les mêmes features et on fait un test pour isoler les cas où tasknum < process_step. On isole les id_request de ces commandes qui sont problématiques.

On supprime ensuite de la table request_history les entrées de ces id_request qui ont un process_step>3 et ensuite on fait un update sur requests et request_history pour tout remettre avec process_step=3, tasknum = 3 et status = 'STANDBY'. On supprime ce qui est au-dessus de 3 car l'étape 3 est l'étape de validation pour cette tâche. Comme ça le géomaticien peut refaire la validation.