• Resolved alpha2

    (@neoseeyou)


    Bonjour,

    Nous rencontrons un nouveau bug étrange, depuis quelques jours, nous avons une commande dans la passerelle qui génère bien le code de suivi colissimo/mr mais nous n’avons pas le lien pdf pour imprimer le bon de livraison. Avez vous deja rencontré cela? Je solutionne la chose en effaçant dans la BDD les metas mais ce n’est pas une solution viable sur le long terme.

    Merci

Viewing 12 replies - 1 through 12 (of 12 total)
  • Plugin Author Halyra

    (@harasse)

    Bonjour,

    Non cas pas encore rencontré.

    Lors d’un prochain incident, pourriez-vous faire les vérifications suivantes :

    1) vérifier dans les logs (CDI + WP) s’il y a une erreur quelconque au moment de la supposée génération de l’étiquette ;

    2) contrôler dans le répertoire /wp-content/uploads/cdistore/ si vous avez un fichier de nom “CDI-label-<id-order>.txt” qui est alors l’étiquette stockée.

    3) contrôler si vous avez dans la table “???_postmeta” de la BDD wordpress, une entrée de nom “_cdi_meta_exist_uploads_label” pour l’ordre “<id-order>” avec la valeur “1” qui signifie qu’une étiquette a été stockée.

    Il faut qu’on arrive à déterminer s’il s’agit d’une absence de la pièce jointe dans la réponse du transporteur ou d’un incident ou bug dans le process de stockage.

    Dans la prochaine version de CDI (5.3.xxx), il aura des logs supplémentaires si cet incident se produit.

    Thread Starter alpha2

    (@neoseeyou)

    Bonjour, merci pour votre retour

    1. Voici le message présent sur cdilog

    [2023-10-23 07:39:01] *** LOG CDI(msg) – LINE:339 FILE:/includes/CDI-Carrier-colissimo/Colissimo-Affranchissement.php ***: Order : 414138 Parcel : 6XXXXXXXXX (j’ai masqué le numéro de suivi)
    [2023-10-23 07:39:10] *** LOG CDI(tec) – LINE:608 FILE:/includes/CDI-Reference-Livraisons.php ***: Customer address fallback.
    [2023-10-23 07:39:13] *** LOG CDI(msg) – LINE:333 FILE:/includes/CDI-Reference-Livraisons.php ***: cdi_shipping_mondialrelay_pick1:35:1
    [2023-10-23 07:39:13] *** LOG CDI(msg) – LINE:334 FILE:/includes/CDI-Reference-Livraisons.php ***: Array
    (
    [0] => 7630
    [1] => 56596
    )

    [2023-10-23 07:39:13] *** LOG CDI(tec) – LINE:608 FILE:/includes/CDI-Reference-Livraisons.php ***: Customer address fallback.

    2. Oui le fichier txt est bien présent dans le répertoire

    3. Je n’ai pas cette entrée ‘_cdi_meta_exist_uploads_label’ dans le post meta de cette commande

    Cela est donc la 4eme fois que ca se produit

    Merci

    Plugin Author Halyra

    (@harasse)

    Bonjour,

    Le point 1) est normal et n’apporte pas d’éléments d’analyse supplémentaires.

    Les points 2) fichier txt présent, et 3) _cdi_meta_exist_uploads_label absent, sont très intriguants.

    En effet, en supposant que la situation est bien relevée dès l’incident, et donc avant de régénérer une autre étiquette pour la commande qui alors remplacera les données précédentes, ces données sont contradictoires. Elles sont générées dans la même séquence courte (function cdi_uploads_put_contents) et ne peuvent qu’ être en cohérence. 

    Je n’ai aucune piste, mais ça ressemble comme si il y avait eu un problème sur la BdD (cache ou autre chose).

    A suivre donc

    Thread Starter alpha2

    (@neoseeyou)

    bonjour et merci pour votre réponse. Y aurait il moyen d’ajouter un Check pour savoir si la meta est présente à la fin du processus ? Et si la méta n’est pas la, de l’ajouter ?

    nous utilisons redis cache object mais nous n’avions pas de souci jusque là

    • This reply was modified 7 months ago by alpha2.
    Thread Starter alpha2

    (@neoseeyou)

    Pour info mon équipe a eu le probleme ce matin et cet apres midi

    Plugin Author Halyra

    (@harasse)

    Bonjour,

    Peu de chance de trouver un contrôle qui soit indépendant du cache, et qui soit aussi visible que l’absence du bouton label sur les pages WC ou CDI.

    En revanche vous devriez tester un contournement, peut-être mieux géré par votre cache :

    Dans le ficher /includes/CDI-Function.php (CDI 5.2.5) ligne 139 :

    … remplacer add_post_meta( $idorder, ‘_cdi_meta_exist_uploads_’ . $type, true, true );

    par update_post_meta( $idorder, ‘_cdi_meta_exist_uploads_’ . $type, true );

    Thread Starter alpha2

    (@neoseeyou)

    merci je vais tester sur notre site live de suite

    Thread Starter alpha2

    (@neoseeyou)

    Bonjour,

    Jusque la mes collègues à la logistique n’ont pas rencontrés le souci à nouveau. Wait and see.

    Merci

    Thread Starter alpha2

    (@neoseeyou)

    J’ai parlé trop vite, cela s’est reproduit sur une autre commande

    Plugin Author Halyra

    (@harasse)

    Bonjour,

    Y a-t-il du nouveau sur ce sujet qui reste en suspens ?

    Avez-vous testé la solution de ne pas avoir sur les base de données, de caches additionnels autres que ceux déjà inclus dans Woocommerce et WordPress ?

    Thread Starter alpha2

    (@neoseeyou)

    Bonjour, je reviens de vacances désolé pour le retard dans ma réponse.

    La dernière alerte s’est avérée ne pas être en rapport avec la problématique de ce thread. Donc depuis la modification que vous m’aviez proposé il semble que mon équipe n’a plus rencontré le souci. Je vous tiens au courant.

    Plugin Author Halyra

    (@harasse)

    Bonjour,

    Je ferme donc le fil puisqu’il s’agit d’un problème de cache gérant imparfaitement les requêtes WordPress.

    J’évite que des caches additionnels portent sur les tables propres au fonctionnement de WordPress et Woocommerce, car ceux-ci ont déjà leurs propres caches. Ça ne fait qu’alourdir par une couche applicative supplémentaire, et occasionnellement introduire quelques bugs. Cette question sera encore plus d’actualité pour les sites basculant sur les tables HPOS.

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘Probleme generation pdf’ is closed to new replies.