He estado ejecutando una instalación de Discourse bastante pequeña durante algunos años. Tiene un tráfico bastante bajo, por lo que tardé un tiempo en darme cuenta de que el envío de correos electrónicos (notificaciones, resúmenes) obviamente comenzó a fallar hace algunos meses. La investigación apunta a la actualización a 2.8.0.beta7 alrededor del 22-10-2022, anteriormente estábamos en 2.8.0.beta4. Al menos no he recibido ningún correo electrónico de esa instalación sobre publicaciones o mensajes.
Los correos electrónicos se acumulan en Sidekiq, con un mensaje que no puedo relacionar, ni encontrar nada que encaje al buscarlo; hubo informes de mensajes de undefined method, pero ninguna de las condiciones coincide con la mía. (No es TLS, no es un tiempo de espera del servidor de correo, no es el plugin de eventos, y la corrección de medios seguros ya debería estar implementada; además, los mensajes de error exactos eran diferentes).
Error en Sidekiq:
Wrapped NoMethodError: undefined method `value' for #<Array:0x00007f7fd5277d68> Did you mean? values_at
La parte después de #<Array: es diferente para cada correo electrónico retenido. Reinstalé Discourse en una nueva VM anoche y restauré desde una copia de seguridad reciente, ¡pero aparentemente el problema del correo electrónico se restauró con los datos
Dado que la tasa de error comenzó a aumentar a fines de octubre, estoy bastante seguro de que esto fue introducido por 2.8.0.beta7:
## Los plugins van aquí
## ver https://meta.discourse.org/t/19157 para más detalles
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
## Cualquier comando personalizado para ejecutar después de la compilación
¿Esta es una instalación estándar? Si tiene un contenedor de datos separado, ¿se ha reconstruido? ¿Está postgres actualizado? (Aunque creo que todavía hay una verificación para esto en el código)
Sí, es una instalación estándar; por lo que puedo ver, solo se está ejecutando un contenedor. (Iniciar una nueva VM, reasignar DNS, apt update, apt dist-upgrade, reiniciar, git pull, ./discourse-setup, configuración basada en web, cargar copia de seguridad, restaurar copia de seguridad, reactivar correo, ver los errores de nuevo). Tenga en cuenta que la instalación anterior pudo enviar por correo el enlace a la copia de seguridad, y el envío de correos de prueba todavía funciona en la nueva instalación; aparentemente, solo los correos relacionados con la publicación fallan.
root@discourse:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ac408a70305d local_discourse/app \"/sbin/boot\" 12 hours ago Up 12 hours 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp app
Editar:
root@discourse:~# apt update
Hit:1 https://download.docker.com/linux/debian buster InRelease
Hit:2 http://deb.debian.org/debian buster InRelease
Get:3 http://deb.debian.org/debian buster-updates InRelease [51,9 kB]
Get:4 http://security.debian.org/debian-security buster/updates InRelease [65,4 kB]
Fetched 117 kB in 2s (60,5 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
Sin embargo, las primeras restauraciones fallaron. database_restorer.rb falló en restore_dump debido a enlaces duplicados en el post_id 3841. Terminé reemplazando estos enlaces en un post de 2017 por una captura de pantalla de ellos en la instalación anterior y haciendo otra copia de seguridad; solo entonces pude restaurar la copia de seguridad en la nueva instalación. Como mencionaste postgres, esto sucedió durante CREATE INDEX con ERROR: could not create unique index \"unique_post_links\". Más información: EXCEPTION: psql failed: DETAIL: Key (topic_id, post_id, url)=(1300, 3841, [redacted]) is duplicated.
Aunque no creo que esto esté directamente relacionado, pensé que debería mencionarlo.
Entonces, si nadie conoce una forma fácil de solucionarlo, depuremos esto correctamente. Pero necesito tu ayuda, ya que Discourse es una aplicación bastante compleja que utiliza un montón de tecnologías con las que no estoy familiarizado. Entonces: ¿Cómo se envían los correos electrónicos a Sidekiq?
¿Qué componente de Discourse le está dando a Sitekiq un método “value”?
Con las notificaciones por correo electrónico dejando de funcionar después de una actualización, Discourse es lamentablemente bastante inútil ahora. En lugar de atención inmediata, los temas ahora tardan días en recibir atención, si es que la reciben, ya que la gente no realiza sondeos activos en 2022. Sin notificación ⇒ no pasó nada ⇒ no es necesario revisar el sitio
Esto parece un índice corrupto. No creo haber visto esto en postgres 13. ¿Parece que los arreglaste en un sitio antiguo y luego actualizaste haciendo una copia de seguridad y restaurando en un sitio nuevo?
Parece que el problema tiene que ver con algo en el código que envía notificaciones, pero es un problema con sidekiq.
Como dije, el sitio antiguo está funcionando, hice una copia de seguridad y la puse en una instalación nueva, la restauración falló. Modifiqué la publicación señalada como culpable hasta que la restauración en la instalación nueva funcionó. Solo para ver que el problema con Sitekiq volvía/persistía.
El sitio antiguo también ejecuta postgres 13 (pero se remonta a varios años, por lo que lo más probable es que no comenzara con esa versión )
root@discourse-old:/var/discourse# ./launcher enter app
Se detectó la arquitectura x86_64.
root@discourse-app:/var/www/discourse# psql --version
psql (PostgreSQL) 13.5 (Debian 13.5-1.pgdg110+1)
Probé con un usuario nuevo, recibe su correo electrónico de registro correctamente. Pero las notificaciones sobre respuestas a sus publicaciones, no; Sidekiq falla.
Entonces, para mí, esto significa que Discourse está proporcionando información defectuosa a Sidekiq cuando le indica que envíe Notificaciones (en contraste con el correo electrónico de registro). ¿Cómo depurar más?
OK, así que si los índices se reparan, esto me sugiere que algo se está llamando con una matriz en lugar de un modelo que tiene value. El problema no es con sidekiq, en sí, sino con la función que sidekiq está provocando que se llame.
Así que parece que algo se está llamando que devuelve una matriz en lugar de un solo elemento, pero no puedo adivinar qué es. Creo que necesitarás mirar en /var/discourse/shared/standalone/logs/rails/production.log (o algo muy parecido si mis dedos o mi memoria me fallan). Luego puedes buscar ese error en esos registros (o hacer que vuelva a ocurrir para que esté al final del archivo). Deberías obtener más información sobre lo que está fallando allí.
Started POST "/sidekiq/retries" for 185.39.142.187 at 2022-04-11 16:31:35 +0000
start
Started GET "/sidekiq/retries" for 185.39.142.187 at 2022-04-11 16:31:35 +0000
Rendered email/notification.html.erb (Duration: 42.8ms | Allocations: 4323)
Rendered layouts/email_template.html.erb (Duration: 0.3ms | Allocations: 29)
Job exception: undefined method `value' for #<Array:0x00007ff393af6c78>
Did you mean? values_at
fail
shared/standalone/log/rails/production_errors.log está vacío.
is – in the Discource code? – where Sidekiq bails out?
This is called from …
228 MessageBuilder.custom_headers(SiteSetting.email_custom_headers).each do |key, _|
*229 value = header_value(key)
230
231 # Remove Auto-Submitted header for group private message emails, it does
232 # not make sense there and may hurt deliverability.
So it could be a custom header?
I indeed do have an entry there:
I’ve reset this to defaults, and … actually it seems that email notifications are indeed been sent out again, as verified by readers.
Thanks!
One question remains, though: Why is »Auto-Submitted: auto-generated|Precedence: bulk« causing this failure? It states that custom headers shall be seperated by »|«.
(Descargo de responsabilidad: no soy programador de ruby)
Creo que este es un comportamiento particularmente desagradable en la biblioteca de correo que está utilizando Discourse. Aquí está la función header_value:
Por lo que puedo decir, @message.header[name] está llamando a este método:
Según RFC, muchos campos pueden aparecer más de una vez, devolveremos una cadena del valor si solo hay un encabezado, o si hay más de un encabezado coincidente, devolveremos una matriz de valores en el orden en que aparecen en el encabezado, ordenados de arriba a abajo.
Discourse establece automáticamente un encabezado Precedence, por lo que, dado que usted también está agregando uno a través de la configuración email_custom_headers, ahora hay dos encabezados Precedence, y @message.header["Precedence"] está devolviendo una matriz en lugar de una cadena.
Creo que este error se activará cada vez que email_custom_headers contenga un encabezado que ya existe en el objeto del mensaje.
Esto me parece lo que está sucediendo (sugerí que algo era una matriz en lugar de un solo elemento, pero no podía imaginar cómo podría ser cierto) y es un error.
Hoy fusioné una corrección para esto; si detectamos una cabecera duplicada, simplemente usamos la definida en el núcleo de Discourse en lugar de la personalizada de la configuración del sitio:
)
