Project

General

Profile

Développement #101578

testdef, exécution automatique vs suppression d'un champ

Added by Valentin Deniaud 8 days ago. Updated about 7 hours ago.

Status:
Solution proposée
Priority:
Normal
Target version:
-
Start date:
03 February 2025
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

Sur un formulaire avec beaucoup de tests, en cas de deux suppressions successives de champs, la première suppression s'exécute normalement (et déclenche donc l'exécution des tests dans un afterjob), mais la deuxième prends longtemps (la page charge pendant des dizaines de secondes).

Reproducible ici https://demarches-saint-chamond.test.entrouvert.org/backoffice/forms/158/fields/

J'en avais parlé rapidement avec PierreD sur jabber, il m'avait évoqué un « lock exclusif » qui est pris le temps de la suppression d'une colonne, sans que ça explique le comportement observé. C'est certainement un point de départ pour investiguer.

(perso pas très inspiré, si des gens veulent aiguiser leurs outils de debug postgres sur ce ticket, feel free)

History

#1

Updated by Frédéric Péters 7 days ago

Je réponds sur le côté mais on pourrait envisager comme c'est le cas pour jenkins sur un commit, d'attendre un peu, sur l'idée qu'après une modif une autre peut rapidement survenir.

#3

Updated by Valentin Deniaud 7 days ago

Frédéric Péters a écrit :

Je réponds sur le côté mais on pourrait envisager comme c'est le cas pour jenkins sur un commit, d'attendre un peu, sur l'idée qu'après une modif une autre peut rapidement survenir.

Ça donnerait un fonctionnement un peu moins clair, actuellement il est documenté que chaque modif déclenche une exécution et que ça permet de pointer dans l'historique quelle modif a cassé/réparé les tests. Sinon il faudra expliquer qu'il y a un délai, que peut être l'historique pointe que telle modif a cassé les tests mais qu'en fait non une autre a eu lieu x secondes avant et que donc délai et qu'il faut étudier les deux.

Ça me va aussi de dire que c'est du détail et donc pas d'opposition ferme à l'idée, mais j'aimerais bien comprendre ce qu'il se passe avant tout de même, il y a sûrement un truc à corriger quelque part

#4

Updated by Benjamin Dauvergne 6 days ago

Je ne vois pas de solution à ce problème, on peut effectivement décaler un run de x secondes, il restera que pendant une transaction les modifications aux schémas des tables sont impossibles, donc si le test prend x secondes pendant ces x secondes les tables concernées ne seront pas modifiables (les requêtes DDL, changement de schéma, tenteront de prendre des verrous exclusifs et seront bloquées par les verrous partagés des SELECT à minima).

Donc le plus simple c'est d'abandonner l'utilisation de atomic() et revenir à quelque chose de plus simple (si possible). L'idée d'avoir un test correspondant à chaque état des schémas sérialisés (donc actuellement en lançant un run_tests() après chaque sauvegarde d'un snapchot du formdef), ça nécessite forcément de sérialiser ces états (ce qui est le cas actuellement ou presque avec atomic(), il y a quand même une race condition entre les requêtes DDL et l'exécution du AfterJob) mais c'est incompatible avec l'idée que les pages de gestion des champs soient réactives.

#5

Updated by Valentin Deniaud 5 days ago

  • Assignee set to Valentin Deniaud
#6

Updated by Robot Gitea about 8 hours ago

  • Status changed from Nouveau to En cours

Valentin Deniaud (vdeniaud) a ouvert une pull request sur Gitea concernant cette demande :

#7

Updated by Robot Gitea about 7 hours ago

  • Status changed from En cours to Solution proposée

Also available in: Atom PDF