Projet

Général

Profil

Development #71368

Connecteur Esabora : lors d'erreurs, retourner les informations renvoyées par Esabora

Ajouté par Marie Kuntz il y a plus d'un an. Mis à jour il y a plus d'un an.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

Description

Sur une action webservice appelant le connecteur Esabora, on a une erreur 400 si on envoie une référence déjà présente dans Esabora.
Par ex : https://passerelle-nantes-metropole.test.entrouvert.org/manage/esabora/esabora-test-recette/logs/?log_id=73360

{"code":"WS_ERR_SQL","message":"23505 - ERREUR: la valeur d'une clé dupliquée rompt la contrainte unique « iaff_cledoss_unik »\nDETAIL: La clé « (iaff_cledoss)=(215-1) » existe déjà."}

Est-il possible de catcher cette erreur dans le connecteur et de renvoyer au workflow l'info "clé dupliquée" (texte non contractuel) plutôt que cette erreur générique ? Ça permettrait une utilisation plus simple du connecteur par les admins fonctionnels.

(Dans l'idéal il faudrait pouvoir le faire pour les erreurs les plus courantes mais je ne connais pas les autres cas d'erreur)

Révisions associées

Révision 56b6baea (diff)
Ajouté par A. Berriot il y a plus d'un an

esabora: return error content in response (#71368)

Historique

#1

Mis à jour par Thomas Noël il y a plus d'un an

Il s'agirait de détecter « clé dupliquée » dans le message d'erreur, pour le remplacer par un message « clé dupliquée » ? Ça me parait pas très utile...

Tu peux déjà faire une analyse au niveau du workflow, en cas d'erreur 400, en regarder si « clé dupliquée » existe dans la réponse, et dans ce cas afficher une (tentative de) message à l'admin fonctionnel.

Je dis "tentative de message" car une telle erreur SQL peut avoir mille causes.

Je pense qu'il est préférable de surtout chercher à l'éviter. Est-ce qu'elle se produit régulièrement ? Dans quel(s) cas ?

#2

Mis à jour par Marie Kuntz il y a plus d'un an

Justement, ce message n'apparait pas dans l'inspecteur, il faut aller chercher dans le connecteur.
Si on pouvait remonter response_content au niveau du wf, ce serait déjà super, ça éviterait qu'on doive faire des AR entre WF et logs du connecteur

#3

Mis à jour par Thomas Noël il y a plus d'un an

  • Sujet changé de Connecteur Esabora : traiter certaines erreurs différemment à Connecteur Esabora : lors d'erreurs, retourner les informations renvoyées par Esabora

Pigé, on a fait de simples « response.raise_for_status() » qui ne renvoient effectivement rien d'utile en dehors du code d'erreur.

Il faut qu'on pose une gestion d'erreur au niveau de la méthode post :
  • si le payload n'est pas du JSON, lever une APIError en y indiquant le status reçu et le payload "brut"
  • si le status de retour n'est pas 2XX alors lever une APIError en y indiquant le status reçu et le json reçu (c'est ce cas qui intéresse Marie)
#4

Mis à jour par Thomas Noël il y a plus d'un an

  • Assigné à mis à A. Berriot
#7

Mis à jour par Robot Gitea il y a plus d'un an

  • Statut changé de Nouveau à En cours

Agate Berriot (aberriot) a ouvert une pull request sur Gitea concernant cette demande :

#8

Mis à jour par Robot Gitea il y a plus d'un an

  • Statut changé de En cours à Solution proposée
#9

Mis à jour par Robot Gitea il y a plus d'un an

  • Statut changé de Solution proposée à Solution validée

Serghei Mihai (smihai) a approuvé une pull request sur Gitea concernant cette demande :

#10

Mis à jour par Robot Gitea il y a plus d'un an

  • Statut changé de Solution validée à Résolu (à déployer)

Agate Berriot (aberriot) a mergé une pull request sur Gitea concernant cette demande :

#11

Mis à jour par Transition automatique il y a plus d'un an

  • Statut changé de Résolu (à déployer) à Solution déployée
#12

Mis à jour par Transition automatique il y a environ un an

Automatic expiration

Formats disponibles : Atom PDF