Import de donnée : Bug d'import sans message d'erreur (vérification des uuid)

[afourneyron]

Bonjour et bonne année 2022 à vous !

Je viens de m'apercevoir lors d'un import de fichier de quelques données (30-50) que le module d'import se met en erreur sans dire de raison juste après la correspondance des nomenclatures. J'avais déjà rencontré une erreur similaire dont j'avais compris l'origine ticket Bug volumes de données trop grand nombre de données à importer en une seule fois.

Cette fois-ci l'erreur est différente, en regardant les requêtes qui passent sur le serveur, on voit la vérification de l'existence des uuid présentes dans notre base et celle dans le jeu de données. (30-50 uuid côté du jeu de donnée, 24M dans la base de donnée)

Visiblement au bout d'un moment, la requête s'arrête sur le serveur et le Géonature arrête l'importation, en restant sur la même page (correspondance des nomenclatures) sans mettre d'erreur. Si je relance plusieurs fois l'opération, le fichier ce met en "import en erreur" sans me donner la cause de l'erreur.

Pour cerner la source de l'erreur nous avons testé un import sans renseigner les uuids, cette fois-ci l'importation ce fait sans problème (l'encodage, les correspondances et le type de fichier ne semble pas être l'erreur)

Ayant beaucoup de vérification de l'existence des uuid à réaliser sur la base (24M de donnée), je soupçonne peut-être un timeout sur un temps de calcul trop long. Avez-vous des idées de la source du problème, ou comment le régler ?

Merci beaucoup encore pour votre travail :)

[camillemonchicourt]

Pouvez vous indiquer votre version de GeoNature et celle du module Import ?

Oui il y a d'autres tickets sur le sujet des vérifications d'UUID je crois.
En effet si on a beaucoup de données dans sa synthèse GeoNature ce contrôle est trop lourd et n'aboutit pas.
C'est pourquoi le module dispose d'un paramètre pour activer ou non ce contrôle.

[TheoLechemia]

Bonjour,
il faudrait aussi les log d'erreur /var/log/geonature.log du moment ou l'erreur s'est produite pour pouvoir diagnostiquer le problème

[lpojgc]

Bonjour !

• version de GN : 2.7.5
• version du module d'import : 1.1.4
  On n'a pas de fichier geonature.log mais gn_errors.log.

Ci-dessous l'extrait des logs.

[camillemonchicourt]

Le paramètre pour activer ou non le contrôle des UUID (non fonctionnel actuellement si on a beaucoup de données dans la synthèse) : https://github.com/PnX-SI/gn_module_import/blob/master/config/conf_gn_module.toml.example#L9-L11
Il est prévu d'améliorer la scalabilité de ce contrôle dans la refactorisation à venir : #257

[TheoLechemia]

Sinon vous pouvez baisser la limite du nombre de donnée à partir duquel l'import se fait en tâche de fond (plus de timeout possible):
https://github.com/PnX-SI/gn_module_import/blob/master/config/conf_gn_module.toml.example#L35

[lpofredc]

Cette vérification est-elle pertinente avec la contrainte d'unicité déjà présente dans la synthèse? A moins qu'elle ne soit nécessaire pour le fonctionnement du module pour faire un retour de conflit à l'utilisateur?

[lpojgc]

Merci @camillemonchicourt et @TheoLechemia , on a des pistes pour avancer sur cet import :-)

[Splendens]

Bonjour,
Je n'ouvre pas de ticket à part car j'ai exactement le même problème.

Infos sur l'instance :
GN 2.9.0
Module import 1.1.7
GUNICORN_TIMEOUT=300
Nombre de données en synthèse : environ 320 000

Problème :
Impossible de faire un import de seulement 140 lignes (timeout).
En désactivant le paramètre de contrôle des UUID (ENABLE_SYNTHESE_UUID_CHECK = false), l'import arrive à aboutir mais prend beaucoup de temps. Pourtant, à peine plus 300 000 données dans la synthèse, ce n'est pas très volumineux en comparaison de ce que peuvent être certaines BD naturalistes.

Comme il y a un travail en cours sur ce module, je décris ce cas si jamais ces infos peuvent être utiles !

[camillemonchicourt]

Oui oui on a clairement identifié un soucis de performance avec la dernière version du module et les dernières versions de GeoNature.
Cela vient d'être corrigé dans une branche : 48c8e25
On devrait faire une PR et sortir une version corrective.

Cela avait aussi été identifié et corrigé dans la branche de développement de la version 1.2.0 en cours de finalisation : e9eb7fb

Tu peux essayer de reporter le fix de ce commit (48c8e25) et nous confirmer si ça corrige ton soucis ?

[Splendens]

Ah oui parfait ! et ça fonctionne bien avec ENABLE_SYNTHESE_UUID_CHECK = true

Merci :)

[camillemonchicourt]

Corrigé dans la 1.1.8.