Produits Entr'ouvert » Passerelle

Le contexte c'est qu'un webservice dont le retour doit être un document (par exemple la récupération d'un fichier via CMIS), il doit pouvoir renvoyer un document qui est du json, et du coup, il faut trouver autre chose que ce même json pour signaler qu'il y a eu erreur.

le retour d'une fonction n'est pas forcément un dictionnaire.

Pour moi il faut ajouter un paramètre "header_error=0" dans render_data() qui ajoute systématiquement le header correspondant dans la réponse ; et l'utiliser dans le self.render_data(..., header_error=data['err']) final de api()

(sans importance, mais: inutile d'ajouter trop de lignes vides, genre celles au dessus des return, tu peux les retirer)

Ensuite, dans les test, il faudrait surtout arriver à tester un endpoint qui casse (prendre un connecteur basique dans ceux qu'on a, genre clicrdv, et simuler une erreur du côté du logiciel tiers)

Mettre le tout dans un seul commit. Et dans le ticket correspondant côté w.c.s. je dis que je ne suis pas grand fan d'appeler ça X-Passerelle-Error.

X-Error-Code ?

X-Men ?

Il faut se coordonner sur le nom des deux côtés donc il faudrait qu'on se mette d'accord.
J'aime bien X-MEN. Je plaisante. X-Error-Code c'est bon? ou un nom en rapport avec to_json.

Pour le coup, tu testes sur arcgis qui n'est pas correct («resp = app.get(url, {'lon': 'lon', 'lat': 'lat'}, status=400)», et non, ça devrait pas être 400)

Tu veux que le test n'est pas bon en lui même ou que je me suis placé dans un test qui ne correspond pas à ce que je teste?

Thomas Noël a écrit :

Pour le coup, tu testes sur arcgis qui n'est pas correct («resp = app.get(url, {'lon': 'lon', 'lat': 'lat'}, status=400)», et non, ça devrait pas être 400)

C'est un 400 parce que c'est une erreur de type d'argument envoyé (une erreur passerelle) et non d'un endpoint distant. C'est dans le meme catégorie qu'une erreur de type missing paremeter

Donc JB, il faudrait plutôt poser ton test sur un connecteur qui répond une erreur de la nouvelle façon, à savoir 200, mais avec un "x-error-code" différent de 0.

(parce que là, on comprend pas super bien, la preuve je me suis fait planter)

Thomas Noël a écrit :

Donc JB, il faudrait plutôt poser ton test sur un connecteur qui répond une erreur de la nouvelle façon, à savoir 200, mais avec un "x-error-code" différent de 0.

Par exemple le connecteur famille: apps.family, sur la récuperation du pdf d'une facture.

Il y a un import pdb dans ton patch.

Alors, ça parlait plus haut de x-error-code, il n'y a pas eu mieux, prenons ça.

Dans le test, en plus de vérifier l'entête, je vérifierais que le statut est bien 200, et que le contenu est bien ce qu'il doit être.

Je fais les modifs.
Je trouve x-error-code très vague, je propose donc x-tojson-err ou x-jsonresponse-err. On sait d'où ça vient.
Si c'est bon j'envoie sinon je garde x-error-code

x-error-code.

    content = result.content.replace('null', 'None')
    data = ast.literal_eval(content)

Uh uh uh. json.loads ?

Vérifier aussi que err_code est dans la réponse.

Ça me semble ok.