Closed kinformatiques closed 8 years ago
Bonjour, il s'agit des logs d'accès, ce sont les logs d'erreur (PHP et HTTP) qui contiennent les éléments de réponse. Généralement les timeout durant la validation de commande viennent d'un module qui se greffe sur celle-ci pour soumettre des données auprès d'un service externe (ERP, plate-forme transporteur/logistique, système de statistiques...). Le problème est (était ?) très courant avec un module SoColissimo mal configuré par exemple (URL du endpoint non configuré).
Je ne sais pas si cela peut aider, mais j'ai trouvé ce log aussi : ERROR 2016/05/09 - 01:39:14: Invalid Argument $mode (must be self::MODE_*) at line 971 in file modules/tggatos/tggatos.php
de quelle version du module s'agit-il ?
Version 4.4.1 du module sur Prestashop 1.6.1.5
L'exception de ce log n'est pas liée à votre problème. Pour les confirmations de commande incomplètes il faut effectuer un profiling en se concentrant sur les hooks pour trouver la partie qui crash ou entraîne un timeout. A chaque fois que l'on m'a commandé une prestation de dépannage sur ce type de panne il s'agissait d'un autre module qui effectuait un ou plusieurs appels HTTP vers des services trop lents à répondre.
Effectivement, cela peut correspondre... Nous avons des soucis peu de temps après une mise à jour du module envoimoinscher.... Je vais essayer de voir ce côté.
Par contre ce qui m'étonne c'est que les commandes payées via PayPal s'intègrent elles correctement. Est-ce possible que le module du transporteur impacte l'intégration des commandes payées par Atos mais pas celles payées par PayPal ?
Par contre ce qui m'étonne c'est que les commandes payées via PayPal s'intègrent elles correctement. Est-ce possible que le module du transporteur impacte l'intégration des commandes payées par Atos mais pas celles payées par PayPal ?
Effectivement, le module paypal devrait lui aussi être touché sauf s'il utilise des statuts différents pour créer la commande (un hook module peut être actif uniquement sur certains statuts mais pas d'autres). Il faut aussi s'intéresser à l'échantillonnage statistique : est-ce que toutes les commandes payées via SIPS sont touchées ? J'ai déjà vu des cas où le hasard induisant en erreur, notamment un dans une configuration similaire : SIPS + PayPal mais qui faisait la très grande majorité des paiements via SIPS, et la plupart des commandes SIPS étaient touchées et aucune PayPal : jusqu'à ce que l'échantillonnage statistique devienne suffisamment grand pour se rééquilibrer : quelques commandes PayPal ont fini par être touchées. Ce n'est pas forcément le cas sur ta boutique, mais je me méfie des conclusions tirées à la va-vite.
Mais encore une fois, plutôt que de tergiverser 107 ans sur les possibilités, il faut plus simplement activer (si nécessaire) et lire les logs d'erreur HTTP et PHP. Il est rare que la réponse ne s'y trouve pas.
Ce sont les logs qui se trouve dans Prestashop (Paramètres avancés -> Logs) ?
Non, ce sont les logs PrestaShop (qui peuvent aussi contenir des informations intéressantes). Pour les logs d'erreur PHP et HTTP il faut vous renseigner auprès de votre hébergeur/sysadmin.
Le problème est peut être suite à la mise à jour de Prestashop
1.6.1.4 -> 1.6.1.5
Je viens de désactiver ces options afin de voir si cela a un impact...
J'ai récupéré les logs.
Ces options ne devraient normalement avoir aucun impact sur la réponse silencieuse.
Bonjour,
Avez vous trouvé quelque chose d'anormal dans les logs ?
Cordialement.
Rémi
Désolé j'ai oublié de vous répondre le week end dernier, non les logs ne contiennent rien de très intéressant, mis à part que la boutique génère un nombre élevé d'erreurs.
Il faut profiler pour trouver la source du timeout.
Bonjour,
Le problème s'est résolu tout seul... Surement avec une mise à jour d'un autre module.
Merci encore pour votre aide.
Bonjour,
Les transaction avec ATOS fonctionne bien mais il doit y avoir un problème sur la confirmation de paiement.
Les commandes s'intègrent mais l'Etat est vide (il devrait avoir "Paiement accepté").![image](https://cloud.githubusercontent.com/assets/19283200/15141836/57d92ab8-16a2-11e6-952a-d5f9863b4940.png)
Et lorsque les clients reviennent sur la boutique, ils ont le message d'erreur suivant :![image](https://cloud.githubusercontent.com/assets/19283200/15141821/3c705b52-16a2-11e6-827d-b1b6496c9071.png)
Voici le log atos d'une commande :![image](https://cloud.githubusercontent.com/assets/19283200/15142058/a331abc4-16a3-11e6-807d-15fa3243563a.png)
Voici les log apache correspondants :![image](https://cloud.githubusercontent.com/assets/19283200/15142506/aeea9046-16a5-11e6-8d30-8684e9c07ed4.png)
Merci d'avance pour votre aide.
Cordialement.
Rémi