Magento 1.9.1 Email Queue no funciona / tiene errores: ¿cómo solucionar problemas y cuál es el mejor parche?


35

En primer lugar, sí, esta es otra pregunta / tema sobre la cola de correo electrónico 1.9.1. Pero no se trata de ningún problema cron (como este o este ) o de que la nueva función de cola no se use (como esta ).

En nuestro caso, tuvimos el problema, que la cola ( core_email_queuey core_email_queue_recipients) simplemente no recibía ningún correo electrónico en nuevos pedidos o actualizaciones de pedidos y, por lo tanto, no se enviaron más correos electrónicos para nada relacionado con pedidos, también cron funciona perfectamente y agrega correos electrónicos manualmente a la cola funciona y los envían.

Lo extraño es que, en nuestro entorno de prueba, todo funcionó. Incluso cuando salimos a la venta hoy en los primeros minutos, todos los correos electrónicos se procesaron, pero después de algunos minutos (sin ninguna modificación adicional en el sistema en vivo, por supuesto) no se agregaron más correos electrónicos nuevos a la cola. Parece que esto sucedió (pero no puedo asegurarlo) cuando el primer cliente usó PayPal Express, que no probamos de antemano: - / Y de hecho estábamos usando algunas anulaciones personalizadas en la lógica de PayPal Express con la sendNewOrderEmail()función anterior. Pero no pudimos hacer que los correos electrónicos volvieran a funcionar incluso después de parchearlos para usarlos queueNewOrderEmail().
Entonces, la primera pregunta sería, ¿es posible que la antigua función desencadenara alguna inconsistencia que 'se rompió' la cola de correo electrónico? ¿O todo esto es solo una gran coincidencia y hay una explicación totalmente diferente?

Como no pudimos encontrar el problema, pero, por supuesto, necesitábamos correos electrónicos para que funcionen nuevamente lo antes posible, fuimos a otra anulación de núcleo. En Mage_Core_Model_Email_Template_Mailer(por supuesto, en una copia local) comentamos la línea 76: ->setQueue($this->getQueue())
Esto parece omitir la cola y todos los correos se envían de la manera anterior.

Sin embargo, como nos gustaría mantener el número de anulaciones de núcleo al mínimo y tampoco podemos decir en este momento si enfrentaremos otros efectos secundarios, otros consejos o soluciones de personas con una comprensión más profunda del código de magento y Cola de correo electrónico sería apreciada.

Actualización para 1.9.2: En la actualización a 1.9.2, observamos más de cerca la cola de correo electrónico nuevamente y no pudimos reproducir el problema. Pero como todavía no tenemos una idea real de cuál era el problema con 1.9.1 y como la anulación Mage_Core_Model_Email_Template_Mailer::send()todavía funciona de la manera descrita aquí, todavía no estamos usando la cola. De esta manera, esperamos no volver a tener el mismo problema después de algún tiempo en producción.

tl; dr: la cola de correo electrónico no funciona en 1.9.1, comentando que la línea 76 Mage_Core_Model_Email_Template_Maileromite la cola de correo electrónico y los correos se envían nuevamente, pero esto no parece una buena solución. ¿Cómo se puede resolver esto mejor?


1
¿Cuántas transacciones de prueba realizó en comparación con cuántas transacciones en vivo se realizaron en los primeros minutos? ¿Fue esta una actualización de una versión anterior y faltan algunos archivos o tienen permisos incorrectos? ¿Qué exception.logtal o posiblemente system.log, hay alguna pista allí?
pspahn

Fue una actualización de 1.9.0.1 y no se realizó a través del Connect-Manager sino de la base de código de Magento, así que dudo que nos falten archivos (también diferimos, coreetc. para garantizar que todo lo que no está personalizado o una extensión esté en su lugar y sin modificaciones y lo es). Los permisos coinciden con la configuración anterior y los registros / informes están limpios.
Jey DWork

¿Es cron configurado igual?
pspahn

Cuando vimos el cambio de correo electrónico en el registro de cambios, cambiamos cron para que se ejecute cada minuto desde cada 5 minutos antes (ya que entendemos el cambio para que, de lo contrario, en el peor de los casos, los clientes tendrían que esperar hasta 5 minutos para recibir sus correos de confirmación). Aparte de eso, no hay cambio y, como se dijo antes, vemos que otros trabajos cron se ejecutan sin problemas. // edit: Probablemente debería agregar que usamos (y siempre usamos) Aoe_Scheduler donde configuramos core_email_queue_send_allque también se ejecute cada minuto y desde donde vemos que realmente se ejecuta.
Jey DWork

Q4 2015 y tengo el mismo problema, puedo confirmar que a las tablas de la cola les faltan entradas para algunos pedidos, una señal clara para confirmar los informes de que no se recibieron correos electrónicos. Desafortunadamente, el registro se desactivó en mi caso, por lo que todavía no tengo errores que buscar. ¿Has aprendido algo nuevo desde que publicaste originalmente que podría ser útil agregar?
Rick Buczynski el

Respuestas:


8

Supongo que la configuración de cron.php para ejecutarse cada minuto ha provocado que muchas cosas se pongan una encima de la otra, es decir, que no finalicen antes de que se ejecute la siguiente tarea programada de la misma naturaleza o similar. Dado que cron.php no estaría al tanto de cada estado. Se podría intentar el mismo registro dos veces, causando alguna extraña excepción que rompa los envíos de correos electrónicos en cola.

Dicho esto, hay Mage::Logexcepciones en el Queue Mailer, por lo que asegurarse de que el registro esté habilitado sería el mejor paso para ayudar a determinar si hay alguna excepción. Puede ser conveniente también ejecutar php -f cron.phpdesde CLI para ver si también está lanzando alguna excepción, es posible que no esté viendo que se ejecuta detrás de escena.

También comenzaría con una simple mail()prueba de PHP para asegurarme de que no se encuentre con ninguna política de spam o tal. Solo para estar seguro de que no es algo más bajo en la pila que causa el problema.

Solo algunas especulaciones, ¡espero que ayude!

* EDITAR *

Use en cron.shlugar de cron.phpcomo lo hará grep pspara ver si ya se está ejecutando un proceso anterior.


Gracias por el aporte, pero estos problemas pueden ser excluidos. El hecho de que el trabajo cron del sistema real se ejecute cada minuto no significa que todos los trabajos cron de Magento lo hagan. En nuestro caso, solo el correo electrónico se configuró para ejecutarse también cada minuto y desde el registro cron de Magentos podemos ver que todos los trabajos cron finalizan con éxito, incluso en minutos "estresantes" (es decir, cada hora más o menos cuando se ejecutan más trabajos a la vez y no solo el correo electrónico ) El registro también está habilitado y no se lanzan excepciones. Se puede excluir el uso de filtros de spam, así como después de la solución que publiqué, todos los correos electrónicos llegan a todos los clientes.
Jey DWork

Es posible que desee probar y habilitar el modo de desarrollador para ver si ayuda a generar alguna excepción que no se registre. Sin embargo, tenga cuidado si está funcionando en producción. ¿También hay registros correlativos del servidor web?
B00MER

2
@JeyDWork, ¿has implementado Aoe_Scheduler ? Esto puede dar buena visibilidad.
Benmarks

2
Me gustaría ver una actualización. La cola de correo electrónico está demostrando ser un desafío para muchos.
puntos de referencia

1
Para mí, estaba usando el estándar de PayPal que necesita la devolución de datos IPN (Notificación de pago instantánea) de PayPal solo para confirmar que el pago fue exitoso y cambiar el estado del pedido a procesamiento / completado y finalmente enviar un correo electrónico ... pero no tenía configurado el dominio real para que mi servidor y vhosts accedieran esa fue la razón por la que PayPal no pudo publicar datos de IPN en magento. Puede consultar el historial de IPN en el perfil de la cuenta comercial de PayPal. Paypal realidad mostró los datos que se supone que debe enviar el estado y fue "volver a intentar" ..
zaw

0

Compruebe si core_email_queue y core_email_queue_recipients tienen AUTO_INCREMENT. Si esas tablas no tienen AI habilitado, no tomará nuevas entradas.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.