GeoNature-citizen icon indicating copy to clipboard operation
GeoNature-citizen copied to clipboard

liste tronquée saisie observation

Open jonath35 opened this issue 3 years ago • 34 comments

Bonjour,

Je me permets une demande ici car malgré mes recherches dans les fichiers du serveur, je ne trouve pas la réponse.

J'ai une liste taxonomique d'environ 3000 taxons utilisée par un programme. Le comportement lors de l'ajout d'une observation semble bon (autocomplete) cependant, je ne peux rechercher et saisir que parmi les 100 premières occurrences de la liste. Lorsque je saisie des caractères du 101eme taxon, je n'ai plus de résultat.

Merci d'avance pour votre aide

gncitizen v 0.99-4

jonath35 avatar Dec 03 '21 09:12 jonath35

Bien vu, Ça semble dû a la pagination de la route de TaxHub.

lpofredc avatar Dec 03 '21 14:12 lpofredc

Je sais pas quelle route de TaxHub est utilisée mais ça vaut peut-être le coup d'utiliser la même qu'Occtax optimisée pour l'autocompletion avec optimisation des résultats, recherche en français ou nom scientifique etc... ?

camillemonchicourt avatar Dec 03 '21 15:12 camillemonchicourt

Merci pour vos retours,

Je me réjouis de voir des réponses mais je suis tout de même inquiet. Je suis surpris que malgré la multiplication des atlas de la biodiversité ce problème n'ait pas été signalé.

Je risque d'avoir un problème dans la mesure où notre atlas doit être opérationnel mi-décembre et que ce comportement était totalement inattendu.

Je suis preneur de pistes de travail. J'avoue que les "routes" ne m'évoquent pas grand chose pour l'instant (api ??)

Merci encore pour votre aide.

jonath35 avatar Dec 03 '21 15:12 jonath35

A ma connaissance, GeoNature-citizen n'a pour le moment été utilisé que pour des programmes avec des listes de taxons très limitées, ce qui fait que le soucis n'a peut-être pas été identifié. Le fonctionnement des listes a été évoqué ici : https://github.com/PnX-SI/GeoNature-citizen/issues/260 et avait été défini initialement ici : https://github.com/PnX-SI/GeoNature-citizen/issues/62

Je ne sais pas exactement où on en est de ces sujets.

A voir quelle route de l'API TaxHub est utilisé, si elle peut être utilisée différemment pour ne pas avoir de limite de nombre de taxons, si il faut faire évoluer la route au niveau de TaxHub, ou si il faut mieux basculer sur une autre route de TaxHub...

camillemonchicourt avatar Dec 03 '21 16:12 camillemonchicourt

Bonjour,

Effectivement si je ne dis pas de bêtises voici les étapes :

  • La liste taxonomique avec ces taxons est initialisée ici : https://github.com/PnX-SI/GeoNature-citizen/blob/2f937ff8e415216af0050fc135019ea600fa9c37/frontend/src/app/programs/observations/form/form.component.ts#L164
  • Qui appelle l'API de citizen pour avoir la liste des taxons : https://github.com/PnX-SI/GeoNature-citizen/blob/2f937ff8e415216af0050fc135019ea600fa9c37/frontend/src/app/api/gnc-programs.service.ts#L169-L181
  • Si on regarde cette api (/taxonomy_lists/<id_liste_taxhub>/species/) dans le backend de citizen :
    • elle appelle cette fonction : https://github.com/PnX-SI/GeoNature-citizen/blob/2f937ff8e415216af0050fc135019ea600fa9c37/backend/gncitizen/core/taxonomy/routes.py#L93
    • qui elle même appelle cette fonction : https://github.com/PnX-SI/GeoNature-citizen/blob/2f937ff8e415216af0050fc135019ea600fa9c37/backend/gncitizen/utils/taxonomy.py#L28-L41
    • qui appelle la route de TaxHub : biblistes/taxons/<id_liste>, qui si on regarde le code de TaxHub :
    • il y a bien une limite de 100 par défaut : https://github.com/PnX-SI/TaxHub/blob/df63ea869b6628f7b68741c65d8333a125c68f2d/apptax/taxonomie/routesbiblistes.py#L154-L157
    • Qui peut être surchargée avec une query string : biblistes/taxons/<id_liste>?limit=5000

Éventuelle solution

Je n'ai pas testé mais je pense qu'il faudrait remplacer le dictionnaire payload : https://github.com/PnX-SI/GeoNature-citizen/blob/2f937ff8e415216af0050fc135019ea600fa9c37/backend/gncitizen/utils/taxonomy.py#L28-L33 Par le code suivant :

payload = {
        "existing": "true",
        "order": "asc",
        "orderby": "taxref.nom_complet",
        "limit": 5000
    }

C'est un fix rapide pour toi mais à terme il faudrait peut-être le rendre paramétrable.

Je teste ça maintenant

En espérant avoir été clair.

mvergez avatar Dec 03 '21 18:12 mvergez

J'ai pas trop le temps de tester sur citizen mais en exécutant ce code Python :

import requests
>>> payload = {
       "existing": "true",
       "order": "asc",
       "orderby": "taxref.nom_complet",
       "limit": 5000
 }
# 100 : id de ma liste taxhub
res = requests.get('http://localhost/taxhub/api/biblistes/taxons/100', params=payload)

J'ai cette requête qui apparaît : GET /api/biblistes/taxons/100?existing=true&order=asc&orderby=taxref.nom_complet&limit=5000

Et j'ai limit : 5000 qui apparait dans la réponse. Donc ça devrait fonctionner 👍

@jonath35, peux-tu me tenir au courant si ça fonctionne chez toi ?

mvergez avatar Dec 03 '21 18:12 mvergez

Bonjour, Merci beaucoup pour ces retours rapides ! J m etais concentré sur le frontend vendredi matin...

Je test ça dès demain matin et vous tiens au courant.

jonath35 avatar Dec 05 '21 12:12 jonath35

Bonjour,

J'ai testé rapidement, mais cela ne semble pas fonctionner. à voir si je m'y prends correctement. Je ne fait que modifier le fichier sur le serveur avec simplement un redémarrage. J'obtiens notamment :

getProgramTaxonomyList failed: Http failure response for http://xyza/api/taxonomy/lists/10000/species: 502 Proxy Error

jonath35 avatar Dec 06 '21 14:12 jonath35

C'est étrange, cela fonctionnait bien avant cette modification ? Car normalement, elle ajoute uniquement un paramètre à la requête taxhub et ne devrait pas faire planter cet appel à l'API citizen. Le "10000" m'interpelle : est-ce bien l'id de la liste taxhub ?

mvergez avatar Dec 06 '21 15:12 mvergez

Oui c'est bien une liste particulière qui fonctionne bien (dans la limite des 100 premières lignes).

Ce qui me questionne le plus, c'est qu'après avoir constaté cela, j'ai tenté de modifier la limite "en dur" dans le fichier :

/apptax/taxonomie/routesbiblistes.py

avec pour résultat un comportement similaire (erreur).

jonath35 avatar Dec 06 '21 15:12 jonath35

Effectivement, c'est étrange. As tu essayé d'écrire directement cet url dans ton navigateur : /api/biblistes/taxons/10000?existing=true&order=asc&orderby=taxref.nom_complet&limit=5000 ? Essaie de regarder dans les logs de Taxhub (dans /home/geonatureadmin/taxhub/var/log) pour voir s'il y a des erreurs

mvergez avatar Dec 06 '21 15:12 mvergez

avec l'url : http://xyza/taxhub/api/biblistes/taxons/10000?existing=true&order=asc&orderby=taxref.nom_complet&limit=5000

J'obtiens bien un résultat json avec les 3102 objets

total 3102
total_filtered 3102
limit 5000
page 1

jonath35 avatar Dec 06 '21 15:12 jonath35

l'adresse : http://xyza/api/taxonomy/lists/10000/species retourne cette erreur :

Proxy Error

The proxy server received an invalid response from an upstream server. The proxy server could not handle the request

Reason: Error reading from remote server

jonath35 avatar Dec 06 '21 17:12 jonath35

Cela vient donc de Citizen, tu as pu regarder les logs ?

mvergez avatar Dec 06 '21 17:12 mvergez

Bonjour,

Je trouve l'erreur suivante dans /var/log/supervisor/frontend_citizen.log :

getProgramObservations id=6 failed: ErrorEvent is not defined getProgramTaxonomyList failed: ErrorEvent is not defined ERROR Error: Cannot find a differ supporting object '[object Object]' of type 'object'. NgFor only supports binding to Iterables such as Arrays. at NgForOf.ngDoCheck (/home/geonatadmin/gncitizen/frontend/dist/server.js:79399:27) at checkAndUpdateDirectiveInline (/home/geonatadmin/gncitizen/frontend/dist/server.js:24210:19) at checkAndUpdateNodeInline (/home/geonatadmin/gncitizen/frontend/dist/server.js:32605:20) at checkAndUpdateNode (/home/geonatadmin/gncitizen/frontend/dist/server.js:32567:16) at prodCheckAndUpdateNode (/home/geonatadmin/gncitizen/frontend/dist/server.js:33108:5) at Object.updateDirectives (/home/geonatadmin/gncitizen/frontend/dist/server.js:342089:2576) at Object.updateDirectives (/home/geonatadmin/gncitizen/frontend/dist/server.js:32896:72) at checkAndUpdateView (/home/geonatadmin/gncitizen/frontend/dist/server.js:32549:14) at callViewAction (/home/geonatadmin/gncitizen/frontend/dist/server.js:32790:21) at execComponentViewsAction (/home/geonatadmin/gncitizen/frontend/dist/server.js:32732:13)

Elle est présente dans le panneau de debugage du navigateur.

Merci

jonath35 avatar Dec 07 '21 08:12 jonath35

Super merci, et as-tu regardé le var/log/gunicorn_gncitizen_errors.log pour voir les erreurs du backend ? Car j'ai l'impression que ça vient de là (car c'est uniquement là que tu as fait la modification normalement ?)

mvergez avatar Dec 07 '21 09:12 mvergez

Merci pour le retour.

Pour le test et l'erreur actuelle, la modification est celle proposée avec le dictionnaire payload (/backend/gncitizen/utils/taxonomy.py)

Par contre je n'ai pas d'erreur backend il me semble. à part un retour"timeout" :

[2021-12-07 09:13:11 +0000] [923] [WARNING] Worker with pid 1976 was terminated due to signal 9 [2021-12-07 09:13:11 +0000] [1988] [INFO] Booting worker with pid: 1988 [2021-12-07 09:13:42 +0000] [923] [CRITICAL] WORKER TIMEOUT (pid:1987) [2021-12-07 09:13:42 +0000] [923] [CRITICAL] WORKER TIMEOUT (pid:1988) [2021-12-07 09:13:42 +0000] [1987] [INFO] Worker exiting (pid: 1987) [2021-12-07 09:13:42 +0000] [1988] [INFO] Worker exiting (pid: 1988) [2021-12-07 09:13:43 +0000] [1998] [INFO] Booting worker with pid: 1998 [2021-12-07 09:13:43 +0000] [923] [WARNING] Worker with pid 1988 was terminated due to signal 9 [2021-12-07 09:13:43 +0000] [1999] [INFO] Booting worker with pid: 1999 [2021-12-07 09:14:15 +0000] [923] [CRITICAL] WORKER TIMEOUT (pid:1998) [2021-12-07 09:14:15 +0000] [1998] [INFO] Worker exiting (pid: 1998) [2021-12-07 09:14:15 +0000] [2009] [INFO] Booting worker with pid: 2009

jonath35 avatar Dec 07 '21 09:12 jonath35

Non c'est juste un moyen d'indiquer le type d'une variable en Python. Mais comme il n'y a pas de vérification de type ici, cela ne pose pas de problème. Ce qui me parait vraiment bizarre, c'est juste en modifiant le dictionnaire payload ça ne marche plus. Peux-tu m'envoyer le fichier taxonomy.py que tu as s'il te plaît ?

mvergez avatar Dec 07 '21 12:12 mvergez

taxonomy_routesbiblistes.zip

C'est dingue de ne même pas pouvoir modifier la valeur 100 dans routesbiblistes.py ..

Merci !

jonath35 avatar Dec 07 '21 12:12 jonath35

Merci pour les fichiers. Ils ont l'air bons. Je ne pense pas que ça vienne de routebiblistes.py car le GET sur http://xyza/taxhub/api/biblistes/taxons/10000?existing=true&order=asc&orderby=taxref.nom_complet&limit=5000 fonctionne. J'ai du mal à comprendre.

Peut-être, essaie de te mettre en mode dev sur le backend de citizen :

  • Soit : poetry run python3 wsgi.py
  • Soit :
    • Charger l'environnement virtuel (poetry shell ou source backend/venv/bin/activate)
    • puis : python wsgi.py

Ensuite entre cet URL dans ton navigateur : http://xyza/api/taxonomy/lists/10000/species Il y aura peut-être des erreurs qui apparaîtront ...

Désolé de ne pas pouvoir t'aider plus...

mvergez avatar Dec 07 '21 13:12 mvergez

Merci pour votre aide,

J'ai stoppé toutes les appli supervisorctl stop all Lancé uniquement taxhub puis exécuté le serveur dans le venv

sur l'url xyza/api/taxonomy/lists/10000/species j'obtiens (dans le navigateur) :

{"message": "'<' not supported between instances of 'NoneType' and 'str'"}

En navigant sur la page programme :

ERROR in app: Exception on /api/programs/6/observations [GET] Traceback (most recent call last): File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask/app.py", line 2447, in wsgi_app response = self.full_dispatch_request() File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask/app.py", line 1952, in full_dispatch_request rv = self.handle_user_exception(e) File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask_cors/extension.py", line 165, in wrapped_function return cors_after_request(app.make_response(f(*args, **kwargs))) File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask_cors/extension.py", line 165, in wrapped_function return cors_after_request(app.make_response(f(*args, **kwargs))) File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask/app.py", line 1821, in handle_user_exception reraise(exc_type, exc_value, tb) File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask/_compat.py", line 39, in reraise raise value File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask/app.py", line 1950, in full_dispatch_request rv = self.dispatch_request() File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask/app.py", line 1936, in dispatch_request return self.view_functionsrule.endpoint File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/utils_flask_sqla/response.py", line 19, in _json_resp res = fn(*args, **kwargs) File "/home/geonatadmin/gncitizen/backend/gncitizen/core/observations/routes.py", line 630, in get_program_observations raise e File "/home/geonatadmin/gncitizen/backend/gncitizen/core/observations/routes.py", line 552, in get_program_observations taxon_repository = mkTaxonRepository(taxhub_list_id) File "/home/geonatadmin/gncitizen/backend/gncitizen/utils/taxonomy.py", line 82, in mkTaxonRepository return sorted(r, key=lambda item: item["nom_francais"]) TypeError: '<' not supported between instances of 'NoneType' and 'str' 127.0.0.1 - - [07/Dec/2021 14:19:18] "GET /api/programs/6/observations HTTP/1.1" 500

jonath35 avatar Dec 07 '21 14:12 jonath35

J'ai obtenu un peu plus de résultat.

il y avait des valeurs nulles dans le champs nom_francais de bib_noms. En effet, j'ai du reprendre une liste basée sur taxref 12 dans une base taxref 14. Cela a visiblement conduit à des valeurs null dans le champs en question et fait planté l'outil.

J'ai pu obtenir un chargement normal avec dans le dictionnaire payload la clé,valeur "limit": 1000 Le chargement est plus long. Lorsque je passe la valeur à 2000 par exemple, le problème se reproduit. Est-ce le timeout ?, ou d'autres valeurs incriminées ??

Je vous remercie d'avoir consacré du temps à m'aider.

jonath35 avatar Dec 07 '21 15:12 jonath35

Super bien joué ! Merci pour tes retours.

Effectivement peut-être cela vient du timeout ici : https://github.com/PnX-SI/GeoNature-citizen/blob/2f937ff8e415216af0050fc135019ea600fa9c37/backend/gncitizen/utils/taxonomy.py#L37 Essaie de le mettre à 10 par exemple.

mvergez avatar Dec 07 '21 15:12 mvergez

Le chargement est vraiment très long / trop long je pense pour un usage normal. J'arrive à un plafond à 1752 lignes. Je n'ai pas trouvé pourquoi ... Le timeout est en secondes ?

jonath35 avatar Dec 07 '21 16:12 jonath35

Ah oui effectivement, très bizarre... Je n'ai pas l'habitude de faire des listes avec autant de taxons. C'est pour cela que j'aurai du mal à t'aider là dessus. Oui le timeout est en secondes normalement

mvergez avatar Dec 07 '21 17:12 mvergez

Comme évoqué, l'idéal serait certainement d'utiliser la route de TaxHub dédiée à la recherche de taxon avec auto-complétion, optimisée en terme de résultat et de pertinence et utilisée dans Occtax. Cela mériterait un petit développement pour basculer sur cette route correctement.

camillemonchicourt avatar Dec 07 '21 17:12 camillemonchicourt

OK je fais une PR dans ce sens

mvergez avatar Dec 07 '21 18:12 mvergez

En effet, il faut limiter au max les surcouches et redondances inutiles.

lpofredc avatar Dec 07 '21 21:12 lpofredc

Pensez-vous que le travail nécessaire est long ? "facile" à reprendre dans un serveur en cours d'utilisation ?

Merci !

jonath35 avatar Dec 08 '21 13:12 jonath35

J'ai un peu commencé, je vais essayer de continuer cette semaine mais je ne peux rien te garantir...

mvergez avatar Dec 08 '21 13:12 mvergez