Development #58925
toulouse_axel: erreur de parsing XML sur une 502
0%
Description
https://sentry.entrouvert.org/entrouvert/nfrance/issues/53957/
XMLSyntaxError: Space required after the Public Identifier, line 1, column 50 (<string>, line 1)
(4 additional frame(s) were not displayed)
...
File "src/lxml/parser.pxi", line 1765, in lxml.etree._parseDoc
File "src/lxml/parser.pxi", line 1127, in lxml.etree._BaseParser._parseDoc
File "src/lxml/parser.pxi", line 601, in lxml.etree._ParserContext._handleParseResultDoc
File "src/lxml/parser.pxi", line 711, in lxml.etree._handleParseResult
File "src/lxml/parser.pxi", line 640, in lxml.etree._raiseParseError
XMLSyntaxError: Invalid XML content received (Space required after the Public Identifier, line 1, column 50)
File "zeep/wsdl/bindings/soap.py", line 170, in process_reply
doc = parse_xml(content, self.transport, settings=client.settings)
File "zeep/loader.py", line 54, in parse_xml
content=content
TransportError: Server returned response (502) with invalid XML: Invalid XML content received (Space required after the Public Identifier, line 1, column 50).
Content: b'<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">\n<html><head>\n<title>502 Proxy Error</title>\n</head><body>\n<h1>Proxy Error</h1>\n<p>The proxy server received an invalid\r\nresponse from an upstream server.<br />\r\nThe proxy server could not handle the request <em><a href="/Axel_WS/AxelWS.php">POST /Axel_WS/AxelWS.php</a></em>.<p>\nReason: <s...
(2 additional frame(s) were not displayed)
...
File "passerelle/contrib/toulouse_axel/models.py", line 895, in pay_invoice
schemas.form_paiement_dui(self, {'PORTAIL': {'DUI': post_data}})
File "passerelle/contrib/utils/axel.py", line 244, in __call__
self.operation, serialized_request, ''
File "zeep/proxy.py", line 42, in __call__
self._op_name, args, kwargs)
File "zeep/wsdl/bindings/soap.py", line 132, in send
return self.process_reply(client, operation_obj, response)
File "zeep/wsdl/bindings/soap.py", line 176, in process_reply
content=response.content)
Error occurred while processing request
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Lauréline Guérin il y a plus de 2 ans
- Projet changé de Suivi des traces à Passerelle
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
- Tags mis à accessible
- Sujet changé de TransportError: Server returned response (502) with invalid XML: Invalid XML content received (Space required aft... à toulouse_axel: erreur de parsing XML sur une 502
Mis à jour par Nicolas Roche il y a plus de 2 ans
- Fichier 0001-axel-handle-transport-errors-58925.patch 0001-axel-handle-transport-errors-58925.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Assigné à mis à Nicolas Roche
- Patch proposed changé de Non à Oui
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
Mouais j'ai oublié si on avait du code dans notre intégration à zeep, mais c'est bizarre de gérer une erreur si bas niveau si haut dans noter code métier. Je dirai que ça devrait être converti bien plus bas en erreur APIError irrécupérable, le truc est en vrac, la 502 l'indique, on devrait même pas parser le contenu renvoyé. (Pour dire que tant qu'à traiter ça il faut le traiter globalement, pas une fois dans chaque connecteur).
Mis à jour par Nicolas Roche il y a plus de 2 ans
On a bien le code de post_xml dans notre intégration mais ici ça plante juste après son appel, sur process_reply.
cf https://github.com/mvantellingen/python-zeep/blob/2f35b7d29355ba646f5e3c6e9925033d5d6df8bb/src/zeep/wsdl/bindings/soap.py#L127
J'ai l'impression que pour traiter l'erreur en dehors des connecteurs Axel il faut passer par du monkey patching,
parce que je ne trouve pas comment attacher l'objet SoapBinding au client SOAP (comme ça a été fait pour post_xml dans passerelle/utils/soap.py).
Pas sûr que ce soit ce qui est attendu ici.
le truc est en vrac, la 502 l'indique, on devrait même pas parser le contenu renvoyé
C'est l'implémentation de process_reply qui veut ça, il parse le contenu à partir du moment ou il y en a, 500 ou pas.
Ensuite seulement il lève la TransportError.
Après (histoire de défendre mon patch), des TransportError c'est fréquent que l'on ait à les gérer dans les connecteurs.
(Dis-moi si tu as une piste, moi je patauge)
Mis à jour par Benjamin Dauvergne il y a presque 2 ans
- Fichier 0001-utils-soap-add-wrapping-of-zeep-errors-inside-APIErr.patch 0001-utils-soap-add-wrapping-of-zeep-errors-inside-APIErr.patch ajouté
- Tracker changé de Bug à Development
Voilà plutôt ce à quoi je pensais.
Mis à jour par Nicolas Roche il y a presque 2 ans
- Assigné à changé de Nicolas Roche à Benjamin Dauvergne
En effet, c'est bien plus propre de le gérer globalement.
Ça me semble tout bon mais j'ai un peu du mal à dérouler du fait que je ne peut pas reproduire l'erreur via mon test (et j'aurais étais plus à l'aise si tu avais seulement activé api_error sur les 2 connecteurs Axel, mais je conviens que c'est mieux partout).
Bref, je me demande si Thomas voudrais bien valider s'il passe par là (parce que je suis encore un peu léger sur soap).
Mis à jour par Thomas Noël il y a presque 2 ans
Nicolas Roche a écrit :
Ça me semble tout bon mais j'ai un peu du mal à dérouler du fait que je ne peut pas reproduire l'erreur via mon test
Je n'ai pas compris cette remarque, veux-tu dire que ce dernier patch ne corrige pas ton problème ? (et lequel ?)
(et j'aurais étais plus à l'aise si tu avais seulement activé api_error sur les 2 connecteurs Axel, mais je conviens que c'est mieux partout).
Je n'ai pas compris non plus cette remarque, je vois bien l'activation spécifique sur Axel via « client = resource.soap_client(api_error=True) », et rien dans maelis, cartads ou atal par exemple.
En plus d'Axel, que ça soit activé sur le connecteur SOAP, ça me va bien, d'autant plus qu'on ne l'a encore jamais utilisé.
Concernant le patch en lui même, je retirerais le "Please contact its administrator" parce que c'est pas forcément sa faute.
Mis à jour par Nicolas Roche il y a presque 2 ans
Je n'ai pas compris cette remarque, veux-tu dire que ce dernier patch ne corrige pas ton problème ? (et lequel ?)
Si, c'est juste que je me basais sur le test que j'avais fourni dans mon patch pour reproduire, et que comme les tests des erreurs bas-niveau ne se font pas dans les tests des connecteurs je suis un peu perdu.
Je n'ai pas compris non plus cette remarque, je vois bien l'activation spécifique sur Axel via « client = resource.soap_client(api_error=True) », et rien dans maelis, cartads ou atal par exemple.
Désolé, j'ai confondu le connecteur soap avec les outils.
Mis à jour par Thomas Noël il y a presque 2 ans
Nicolas Roche a écrit :
Je n'ai pas compris cette remarque, veux-tu dire que ce dernier patch ne corrige pas ton problème ? (et lequel ?)
Si, c'est juste que je me basais sur le test que j'avais fourni dans mon patch pour reproduire, et que comme les tests des erreurs bas-niveau ne se font pas dans les tests des connecteurs je suis un peu perdu.
Ok, ce que tu veux dire c'est que tu voudrais l'ajout d'un test dans tests/test_toulouse_axel.py (et pas uniquement dans les génériques test_soap.py et test_utils_soap.py
Ca peut s'entendre vu que le patch joue dans passerelle/contrib/utils/axel.py
Mis à jour par Nicolas Roche il y a presque 2 ans
Oui, enfin je veux dire que si j'avais été capable (ça ne me semble pas évident) d'écrire ce test alors j'aurais validé le patch direct
(ou si j'avais compris qu'il ne s'applique qu'à Axel et au connecteur soap, mais je te laisse la main).
Mis à jour par Benjamin Dauvergne il y a presque 2 ans
Nicolas Roche a écrit :
Oui, enfin je veux dire que si j'avais été capable (ça ne me semble pas évident) d'écrire ce test alors j'aurais validé le patch direct
(ou si j'avais compris qu'il ne s'applique qu'à Axel et au connecteur soap, mais je te laisse la main).
Ça teste exactement ça, une TransportError ou bien tu veux dire que tu veux voir sur une XMLSyntaxError (on peut toutes les faire mais ça donne une TransportError à la fin depuis l'intérieur de OperationProxy.__call__ donc c'est pareil).
Mis à jour par Benjamin Dauvergne il y a presque 2 ans
Thomas Noël a écrit :
Ca peut s'entendre vu que le patch joue dans passerelle/contrib/utils/axel.py
Pour moi il faut rester au niveau des tests unitaires, on fait beaucoup trop de tests d'intégration trop compliqués qui sont inutiles, si le framework est bon c'est bon aussi par dessus.
Mis à jour par Thomas Noël il y a presque 2 ans
- Statut changé de Solution proposée à Solution validée
Ca me va et je me permets de valider.
Mis à jour par Benjamin Dauvergne il y a presque 2 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 1ec9dbcb130173f40ff584304ed14a17b2262917
Author: Benjamin Dauvergne <bdauvergne@entrouvert.com>
Date: Wed May 25 18:46:12 2022 +0200
utils/soap: add wrapping of zeep errors inside APIError (#58925)Mis à jour par Benjamin Dauvergne il y a presque 2 ans
- Lié à Development #65763: soap: activer api_error=True sur tous les utilisateurs de soap_client() ajouté
Mis à jour par Transition automatique il y a presque 2 ans
- Statut changé de Résolu (à déployer) à Solution déployée
utils/soap: add wrapping of zeep errors inside APIError (#58925)