Development #71368
Connecteur Esabora : lors d'erreurs, retourner les informations renvoyées par Esabora
0%
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
Historique
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 ?
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
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éthodepost
:
- 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)
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 :
- URL : https://gitea.entrouvert.org/entrouvert/passerelle/pulls/3
- Titre : esabora: return error content in response (#71368)
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 :
- URL : https://gitea.entrouvert.org/entrouvert/passerelle/pulls/3
- Commentaire :
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 :
- URL : https://gitea.entrouvert.org/entrouvert/passerelle/pulls/3
- Titre : esabora: return error content in response (#71368)
Mis à jour par Transition automatique il y a plus d'un an
- Statut changé de Résolu (à déployer) à Solution déployée
esabora: return error content in response (#71368)