search

PnX-SI / gn_mobile_occtax

Application mobile pour la saisie dans le module Occtax de GeoNature
GNU General Public License v3.0
13 stars 4 forks source link

0 taxons dans l'appli #147

Closed aferchal closed 2 years ago

aferchal commented 2 years ago

Suite à une mise à jour massive en base des taxons dans la table taxonomie.bib_nom et mise à jour de la liste du jdd occtax de la table taxonomie.cor_nom_liste il y a une semaine, soit un total de 23751 taxons je n'avais pas fait de synchro sur le mobile. J'ai installé hier GN mobile sur les terminaux de nouveaux agents et je me suis retrouvé face à un pb de synchro des taxons avec aucun taxon qui ne remonte.

Les anciennes install sont restées bloquées à une date antérieure. Version GN : 2.6.2 (BRGM) Version TH : 1.9.1 ? (BRGM) Android 10 (Crosscall X4) Sync : 1.3.0 Occtax : 1.3.0 (testé en 1.3.1)

Ci dessous le json :

{
  "geonature_url":  "https://geonature.guadeloupe-parcnational.fr/geonature",
  "taxhub_url":  "https://geonature.guadeloupe-parcnational.fr/taxhub",
  "uh_application_id": 3,
  "observers_list_id": 1,
  "taxa_list_id": 100,
  "page_size": 3000,
  "page_max_retry": 10
}

Ci dessous un extrait du log avec un retour d'erreur indiqué :

04-22 17:09:43.708  4671 18125 I fr.geonature.sync.sync.worker.DataSyncWorker: synchronize taxa...
04-22 17:09:44.875  4671  4723 E WM-WorkerWrapper: Work [ id=5479a36a-1827-4697-a8e9-476920483553, tags={ fr.geonature.sync.sync.worker.DataSyncWorker, data_sync_worker_tag } ] failed because it threw an exception/error
04-22 17:09:44.875  4671  4723 E WM-WorkerWrapper:  at fr.geonature.commons.data.Taxonomy.<init>(Unknown Source:2)
04-22 17:09:44.875  4671  4723 E WM-WorkerWrapper:  at fr.geonature.sync.sync.worker.DataSyncWorker$syncTaxa$taxa$1.invoke(DataSyncWorker.kt:796)
04-22 17:09:44.875  4671  4723 E WM-WorkerWrapper:  at fr.geonature.sync.sync.worker.DataSyncWorker$syncTaxa$taxa$1.invoke(DataSyncWorker.kt:793)
04-22 17:09:44.875  4671  4723 E WM-WorkerWrapper:  at fr.geonature.sync.sync.worker.DataSyncWorker.syncTaxa(DataSyncWorker.kt:811)
04-22 17:09:44.875  4671  4723 E WM-WorkerWrapper:  at fr.geonature.sync.sync.worker.DataSyncWorker.access$syncTaxa(DataSyncWorker.kt:53)
04-22 17:09:44.875  4671  4723 E WM-WorkerWrapper:  at fr.geonature.sync.sync.worker.DataSyncWorker$syncTaxa$1.invokeSuspend(Unknown Source:19)
04-22 17:09:44.877  4671  4723 I WM-WorkerWrapper: Worker result FAILURE for Work [ id=5479a36a-1827-4697-a8e9-476920483553, tags={ fr.geonature.sync.sync.worker.DataSyncWorker, data_sync_worker_tag } ]

J'ai lu pas mal de tickets sur les config du page_size et page_max_retry, mais testé pas mal de valeurs mais pas mieux.

Merci.

camillemonchicourt commented 2 years ago

Salut, j'ai testé la route qui renvoie les taxons et ta liste 100 et elle est OK et renvoie bien 25575 taxons : https://geonature.guadeloupe-parcnational.fr/taxhub/api/taxref/allnamebylist/100?limit=50000

Ta configuration me semble bonne aussi.

Le paramètre page_max_retry a été supprimé depuis la version 1.2.0, donc il n'a plus d'effet. Le module de synchronisation va boucler sur la route en récupérant à chaque fois autant de résultats qu'indiqué par le paramètre page_size et quand il ne trouve plus de résultats, s'arrêter.

Il y a un soucis avec la pagination des routes dans TaxHub qui a été réglé dans sa version 1.9.4 qui faisait qu'il pouvait manquer certains taxons : https://github.com/PnX-SI/TaxHub/releases

Mais cela n'explique pas ton soucis, qui n'est jamais remonté à ma connaissance.

Ce que je comprends de l'erreur (sans certitude), c'est que l'application plante car le terminal sature. Ou alors c'est le TaxHub qui sature et n'arrive plus à répondre ?

Essaie peut-être de mettre une plus grosse valeur au paramètre page_size, genre 30000 (supérieur au nombre d'objets renvoyés par la route, pour tous les récupérer en une fois), ou au contraire mettre une petite valeur comme 200 pour faire plein de petits appels à la route, plutôt qu'un seul gros appel, pour voir si la synchronisation arrive au bout ?

aferchal commented 2 years ago

Bonjour

Merci pour ta réponse. J'ai supprimé le page_max_retry et testé avec les 2 paramètres pour le page_size avec un bas genre 200 et un haut genre 30000. Le résultat est le même : failed because it threw an exception/error Soit il faut réduire le nombre de taxons dans le taxhub, soit il faut que le BRGM mette à jour l'appli pour sen sortir

camillemonchicourt commented 2 years ago

OK. On a déjà testé avec plus de taxons, et la mise à jour de TaxHub réglera les listes de taxons incomplètes mais ne devrait rien changer à ton soucis où le chargement des taxons plante.

Ma compréhension (sans grande compétence sur le sujet) c'est le terminal qui mouline et arrive pas au bout de la synchronisation. Peut-être qu'il manque de ressources ?

aferchal commented 2 years ago

j'ai essayé avec plusieurs terminaux récents, en Android 10 et 11 et le résultat est le même. Je vais tester en réduisant le nombre de taxons dans la liste.

camillemonchicourt commented 2 years ago

Ouais ou alors créé une liste bidon avec 10 taxons pour voir...

sgrimault commented 2 years ago

Bonjour,

J'ai fais une passe rapide sur votre instance, notamment en appelant manuellement la route utilisée par "Occtax" lors de la synchronisation des taxons (/api/taxref/allnamebylist/100) et j'ai trouvé un taxon qui peut poser problème :

{
  "cd_nom": 349525,
  "search_name": "Biota =  <i> Biota Endl.(D.Don)</i> - [Dumm - 349525]",
  "cd_ref": 349525,
  "nom_valide": "Biota Endl.(D.Don)",
  "lb_nom": "Biota",
  "nom_vern": null,
  "regne": null,
  "group2_inpn": "Autres"
}

où les informations sur la taxonomie est incomplète (attribut regne ayant une valeur nulle). Coté application ces informations sont considérés comme obligatoires, notamment pour cataloguer et pouvoir appliquer des filtres sur la liste des taxons. Le problème reste identique sur la v2 de "Occtax" où il n'y a pas de contrôle de fait sur ce point là.

Coté application, je peux donc durcir les contrôles et écarter lors de la synchronisation tout taxon considéré comme non valide, et en attendant, soit vous appliquez une correction en base sur ce taxon, soit vous le supprimez.

camillemonchicourt commented 2 years ago

OK ça devient plus clair, en effet. Merci d'avoir regardé.

En effet, il serait utile d'ignorer les données qui posent soucis, plutôt que de planter le téléchargement de la liste.

Merci.

aferchal commented 2 years ago

Bien vu @sgrimault !! J'ai supprimé ce taxon est la synchro fonctionne. Du même avis que Camille même si une fois qu'on le sait ça va plus vite pour l'identification du pb. Merci à vous.

camillemonchicourt commented 2 years ago

Idéalement, il est peut-être faisable qu'un taxon soit récupéré même si il n'a pas de règne ou de group2inpn (même si ce n'est pas censé arriver à ma connaissance) ?

PS : Alain, tu peux aussi ajouter un règne à ce taxon.

TheoLechemia commented 2 years ago

Oui il faudrait que la synchro continue en ignorant le taxon qui provoque l'erreur. Est-ce qu'il est possible ausi d'avoir des logs un peu plus verbeux ? 04-22 17:09:44.875 4671 4723 E WM-WorkerWrapper: Work [ id=5479a36a-1827-4697-a8e9-476920483553, tags={ fr.geonature.sync.sync.worker.DataSyncWorker, data_sync_worker_tag } ] failed because it threw an exception/error

Là on voit qu'une erreur est levée, mais on ne sait pas laquelle

sgrimault commented 2 years ago

C'est un cas qui ne devrait jamais arriver car ça carrément fait planter le worker dédié à la synchronisation des données.

Je vais donc réactiver la validation stricte sur les taxons reçus et ne garder que ceux qui sont valides. Ceux qui ne passent pas cette validation seront tracés pour faciliter l'analyse si jamais on constate des écarts entre les taxons présents coté GeoNature et ceux présents localement coté "Occtax".

sgrimault commented 2 years ago

La version 2.1.0-rc0 de l'application applique désormais une validation lors de la synchronisation des taxons. Ceux qui échouent à cette validation sont tracés dans les logs pour analyse.