Closed romaintailhurat closed 8 months ago
This is currently more of a background task to check for reproducible paths and buggy code.
Trying to reproduce the bug in this questionnaire.
@loichenninger stumble upon a piece of code that under certain circumstances can delete computed variables. This trail is currently not validated, but nonetheless it's a trail. It implies the use and modification of loops and filters.
Too complicated (and time consuming) to find the buggy path in the application code. Next strategy is to alert the user (via a pop-up or warning message) that they lost all their computed variables. This message ask the user to send a mail to the product team in order to identifiy the previous actions (and so help with a diagnosis).
Message to be displayed →
🇫🇷 Il n'y a plus de variable calculée dans votre questionnaire. Si ce n'est pas une action voulue de votre part, il s'agit probablement d'une erreur de l'application. Dans ce cas, veuillez contacter au plus vite l'équipe de l'atelier de conception pour que nous corrigions ce problème. Par ailleurs, si vous quittez votre questionnaire maintenant sans le sauvegarder, vous retrouverez les variables calculées en retournant sur le questionnaire.
with this mailto on "l'équipe de l'atelier de conception":
mailto:romain.tailhurat@insee.fr,anne.husseini-skalitz@insee.fr, ophelie.rogel@insee.fr, loic.henninger@insee.fr
Bug when creating a new questionnaire the second time. WIP.
@BulotF @ORogel La solution d'alerte ne fonctionne visiblement pas, les nouvelles occurrences du bug ne l'ont jamais levées. Il faut que l'on rediscute de la stratégie d'élimination de ce bug :(
An interesting news: this problem existed six years ago and was corrected. Probably something broke this fix. François will follow this trail.
🇫🇷 Il y a 6 ans, il y a eu un problème dans la gestion du store Redux pour les variables externes et calculées : Le fonctionnement attendu était de recopier le state et le surcharger avec les variables modifiées. Au lieu de ça, le state était écrasé avec les variables calculées et modifiées fournies à l'étape update.
Ainsi lorsqu'on modifiait un composant, les variables externes et calculées étaient effacées.
La correction mise en place il y a 6 ans a consisté à prendre les variables calculées et externes du store et à les recopier lors de l'appel à la modification d'un élément.
Depuis, les variables externes et calculées sont récupérées et envoyées lors de l'appel à la modification d'un élément.
Sauf dans au moins un cas.
Le cas identifié nécessite au moins 3 boucles : La boucle 3 est liée à la boucle 2 (qui est donc une boucle principale) La perte des variables externes et calculées peut arriver lorsque la boucle 2 devient liée à la boucle 1 (la boucle 3 devient alors liée à la boucle 1 au lieu de la 2)
Je n'ai pas réussi à identifier d'autre cas, mais je ne garantis pas qu'il n'en reste pas.
2 possibilités de correction :
🇬🇧 You can use a translator, as I would have to...
🇬🇧 We go for the first solution: patching for this wrong behavior only.
🇫🇷 On part sur la première solution de correction du cas rare.
Situation source du bug finalement trouvée grâce à une conceptrice : le déplacement d'un élément de questionnaire (séquence ou question a priori) pour lequel il existe un filtre dont il est :
Autre cas trouvé (mais a priori innocent des cas remontés par les concepteurs) :
At least two users have lost all their questionnaire computed variables. It's a huge bug because there's no real backup for this once a questionnaire is saved.
Currently, we don't have a clear idea of the path to this bug, extensive research must be done: