Project

General

Profile

Development #71368

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

Added by Marie Kuntz over 1 year ago. Updated over 1 year ago.

Status:
Fermé
Priority:
Normal
Assignee:
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

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)

Associated revisions

Revision 56b6baea (diff)
Added by A. B. over 1 year ago

esabora: return error content in response (#71368)

History

#1

Updated by Thomas Noël over 1 year ago

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

Updated by Marie Kuntz over 1 year ago

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

Updated by Thomas Noël over 1 year ago

  • Subject changed from Connecteur Esabora : traiter certaines erreurs différemment to 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

Updated by Thomas Noël over 1 year ago

  • Assignee set to A. B.
#7

Updated by Robot Gitea over 1 year ago

  • Status changed from Nouveau to En cours

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

#8

Updated by Robot Gitea over 1 year ago

  • Status changed from En cours to Solution proposée
#9

Updated by Robot Gitea over 1 year ago

  • Status changed from Solution proposée to Solution validée

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

#10

Updated by Robot Gitea over 1 year ago

  • Status changed from Solution validée to Résolu (à déployer)

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

#11

Updated by Transition automatique over 1 year ago

  • Status changed from Résolu (à déployer) to Solution déployée
#12

Updated by Transition automatique over 1 year ago

Automatic expiration

Also available in: Atom PDF