-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Erreurs lors du chargement des vocabulaires par API #12
Comments
Est-il possible de questionner Farmin ? Il me semble qu'ils avaient beaucoup bricolé les droits de la DB sans qu'on sache précisément au final ce qui a été fait (ou alors j'ai oublié)... |
@bchossat oui c'est possible, je peux te laisser voir directement avec lui ? Je suis en congé demain aprem. |
Peut-être redondant avec des discussions que vous avez déjà eues avec Erwan, mais ils nous ont bien dit précisément quels droits étaient accordés :
Autrement dit, le rôle Je ne pense pas qu'il s'agisse d'un problème de droit du tout. Avant de parler de leur mise en base, il semble que la récupération des vocabulaires depuis les registres distants échoue - cf. toutes les erreurs "Erreur lors du chargement du vocabulaire".
Il peut y avoir toutes sortes de causes, et nous allons perdre beaucoup de temps pour rien si nous commençons à débugger sur une branche Sauf à ce que vous ayez d'autres raisons de croire que les droits sur la base sont en cause, je pense qu'il vaut mieux ne pas solliciter DAM avant d'être sûrs que le sujet les concerne. @streino va essayer de reproduire le problème en local. S'il n'y parvient pas, je vais de toute façon faire en sorte de finaliser la fusion des branches d'ici mercredi, pour que nous puissions redéployer et reprendre les tests avec un code à jour au plus vite. |
Vous avez raison Leslie, l'ordre chronologique des logs est bien de bas en haut (je me suis fait avoir) et les erreurs de chargement précèdent les erreurs de création de tables. Ajout après avoir lu le code source : pas certain qu'il s'agisse de requêtes réseau dans ces chargements |
Je n'ai pas l'erreur en local sur la branche "develop". Sur la branche "fix/spatial-for-merge" (j'ai changé le code pour utiliser le schéma "public" au lieu de "vocabulary") j'ai des erreurs sur certaines tables seulement, et ça ne me semble pas être le même problème que celui qu'on rencontre sur preprod :
|
@streino @bchossat Ne pas avoir l'erreur en local, ça plaiderait bien pour un problème avec les requêtes réseau ? Vous avez dû voir ça, mais c'est cette fonction qui exécute les requêtes :
Concrètement, elle utilise la fonction Je ne maîtrise pas du tout ces sujets, mais je m'inquiétais du fait qu'elle soit appelée sans le paramètre Pour les erreurs sur |
Les proxies sont positionnés dans les variables d'environnement http_proxy, https_proxy (et no_proxy) (cf fin du tableau des variables d'env ==> https://portail-support.din.developpement-durable.gouv.fr/projects/guichet-donnees/wiki ).
On va y arriver, certainement une contrainte d'environnement bien verrouillé pas bien saisie comme ça a déjà été le cas. |
Le proxy laisse passer les requêtes de moissonnage, je ne vois pas pourquoi il bloquerait les requêtes pour les vocabulaires ? Ou est-ce que je mélange les environnements et les moissonnages n'ont pas été testés non plus sur la pré-prod ? L'applicatif est capable de fournir la description des erreurs, ça fait des semaines que je répète que c'est nécessaire - cf. partie Gestion des erreurs du premier message de l'issue #1. En tout cas, à ce stade, je ne vois pas comment faire sans. Très précisément, si on se base sur le code de la branche
for name in vocab_to_load:
try:
print("vocab_to_load: ",name)
vocab_data=VocabularyIndex.load(name).data
if not vocab_data:
raise Exception(f"Erreur lors du chargement du vocabulaire {name}")
continue
for table_name in vocab_data.keys():
# ...
except Exception as e:
print("Erreur pendant le chargement des vocabulaires",str(e)) par quelque chose comme ça : for name in vocab_to_load:
try:
logger.debug(f'Loading vocabulary "{name}"')
result = VocabularyIndex.load(name)
if result.status_code == 1: # erreur critique
raise result.log[-1]
if result.status_code == 2: # erreur non critique
for e in result.log:
logger.warning(
'Anomaly while loading vocabulary "{}". {}'.format(
name, str(e)
)
)
vocab_data = result.data
for table_name in vocab_data.keys():
# ...
except Exception as e:
logger.error(
'Failed to load vocabulary "{}". {}'.format(name, str(e))
) Remplacer les Comment voulez-vous procéder ? |
Pour info, toutes les erreurs semblables aux suivantes n'ont rien à voir avec des vocabulaires qui auraient pu être récupérés depuis la source distante et qui provoqueraient des erreurs au moment de les mettre en base.
Je suis à peu près certaine qu'elles viennent du module
Accessoirement, je vais corriger pour qu'on ait des logs propres qui indiquent le nom du module et pas |
Vu par mail jusqu'ici avec @asboukerram et @bchossat. Je crée un ticket pour suivre le sujet.
On a des erreurs lors du chargement des vocabulaires par API (commandes exécutées par @asboukerram pour ses tests, le dev étant en cours de finalisation) :
J'ai retiré les 302 et 304 car ça faisait trop à afficher et ça ne me semblait pas utile. Par contre j'ai du garder les 200 car les erreurs de vocab sont en INFO 200.
Remarque : @asboukerram il faut que les messages contenant "Erreur" passent en ERROR ou a minima WARN pour pouvoir mettre en place du filtrage et/ou alerting.
The text was updated successfully, but these errors were encountered: