Probleme generation pdf

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.

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

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

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 1 year, 4 months ago by alpha2.

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

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 );

merci je vais tester sur notre site live de suite

Bonjour,

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

Merci

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

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 ?

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.

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.