¿Problema de regresión posible del evento post_edited?

Informe de error de Discourse: Regresión del evento :post_edited en latest-release

Afecta a: Rama latest-release de Discourse (release +122)
Estado: Regresión confirmada - reproducible
Fecha: 15 de enero de 2026


Resumen

El DiscourseEvent :post_edited dejó de publicarse en las compilaciones recientes de latest-release. Las ediciones de publicaciones se completan con éxito y se crean revisiones, pero el evento del que dependen los complementos nunca se activa. Esto rompe todos los complementos que utilizan el disparador de automatización post_created_edited y cualquier otro complemento que escuche los eventos :post_edited.


Reproducción (Confirmada)

Confirmamos que se trata de una regresión probando en dos entornos Azure AKS idénticos:

Antes de la actualización (Funcionando)

  • Versión: v2026.1.0-latest (compilación anterior)
  • Comportamiento: :white_check_mark: Los eventos :post_edited se activan correctamente
  • Automatización: :white_check_mark: Funciona automáticamente

Después de la actualización (Roto)

  • Versión: latest-release +1221 hours ago, release +122
  • Comportamiento: :cross_mark: Los eventos :post_edited nunca se activan
  • Automatización: :cross_mark: Completamente rota

Hallazgo crítico: Ambos entornos funcionaban antes de la actualización. Ambos se rompieron después de actualizar a latest-release +122. Esto demuestra de manera concluyente que se introdujo una regresión.


Detalles del entorno

  • Versión de Discourse: latest-release (release +122)
  • Versión de Rails: 8.0.4
  • Infraestructura: Azure Kubernetes Service (AKS)
  • Imagen de Docker: discourse/base:2.0.20260109-0020
  • Despliegue: Instalación estándar de Docker de Discourse

Procedimiento de prueba

Prueba 1: Escuchador de eventos (Demuestra que el evento nunca se activa)

# En la consola de Rails
File.open('/tmp/post_edited_test.log', 'w') { |f| f.write("Test started at #{Time.now}\n") }

DiscourseEvent.on(:post_edited) do |post, topic_changed, revisor|
  File.open('/tmp/post_edited_test.log', 'a') do |f|
    f.write("[#{Time.now}] :post_edited fired! Post #{post.id}\n")
  end
end

Luego edite cualquier publicación a través de la interfaz web y verifique:

cat /tmp/post_edited_test.log

Resultado en latest-release +122: Solo muestra “Test started” - el evento nunca se activa
Resultado en la compilación anterior: Muestra entradas de eventos con marcas de tiempo e IDs de publicación

Prueba 2: Verificar que se crean revisiones

post = Post.find(POST_ID)
puts "Post revisions: #{post.revisions.count}"
post.revisions.last(3).each { |rev| puts "  Revision #{rev.number}: #{rev.created_at}" }

Resultado: Las revisiones SÍ se crean correctamente con las marcas de tiempo adecuadas
Conclusión: Las ediciones se procesan correctamente, pero post_process_post no se llama o el evento no se activa

Prueba 3: Activación manual del evento (Demuestra que el sistema de eventos funciona)

post = Post.find(POST_ID)
DiscourseEvent.trigger(:post_edited, post, false, PostRevisor.new(post))

Resultado: Los controladores de eventos se ejecutan correctamente
Conclusión: El sistema de eventos funciona, pero la activación automática durante las ediciones está rota


Comportamiento esperado

Cuando se edita una publicación a través de la interfaz web:

  1. La edición se guarda correctamente :white_check_mark:
  2. Se crea una revisión de la publicación :white_check_mark:
  3. Se llama a PostRevisor#post_process_post :cross_mark:
  4. Se activa el evento :post_edited :cross_mark:
  5. Los controladores de eventos se ejecutan :cross_mark:

Solo funcionan los pasos 1-2. Los pasos 3-5 están rotos.


Comportamiento real

Los registros de producción muestran una finalización de edición exitosa:

Started PUT "/posts/3631" for 88.97.179.124 at 2026-01-15 13:06:19 +0000
Processing by PostsController#update as JSON
Completed 200 OK in 676ms

Sin errores, sin excepciones, pero sin publicar ningún evento :post_edited.

El evento debería activarse en /var/www/discourse/lib/post_revisor.rb línea 759:

def post_process_post
  @post.invalidate_oneboxes = true
  @post.trigger_post_process
  DiscourseEvent.trigger(:post_edited, @post, self.topic_changed?, self)
end

Este método se llama desde la línea 341, pero el evento no se está disparando.


Impacto

Funciones oficiales afectadas

  • Automatización de Discourse: El disparador post_created_edited está completamente roto
  • Cualquier flujo de trabajo de automatización que dependa de las ediciones de publicaciones falla silenciosamente

Complementos afectados

Todos los complementos que escuchan los eventos :post_edited están rotos:

  • discourse-automation - Disparadores de automatización oficiales
  • discourse-ai - Moderación de IA en publicaciones editadas
  • discourse-doc-categories - Actualizaciones de índices de documentación
  • discourse-topic-voting - Flujos de trabajo de recuperación de votos
  • Cualquier complemento personalizado que utilice eventos de edición de publicaciones

Cronología de la regresión

  1. Compilación anterior: v2026.1.0-latest - Los eventos :post_edited funcionaban :white_check_mark:
  2. Actualizado a: latest-release (release +122) - Los eventos :post_edited están rotos :cross_mark:
  3. Confirmado en: Dos entornos de producción independientes (ambos se rompieron después de la actualización)

Esto demuestra de manera concluyente que se introdujo una regresión en las compilaciones recientes de latest-release.


Solución alternativa

La activación manual a través de la consola de Rails funciona:

automation = DiscourseAutomation::Automation.find(AUTOMATION_ID)
post = Post.find(POST_ID)
automation.trigger!({"post" => post})

Esto confirma que el sistema de automatización en sí funciona; solo la activación automática de eventos está rota.


Notas de configuración

  • Configuración verificada: Todas las configuraciones relacionadas con la edición son estándar/predeterminadas
  • Período de gracia: Probado con ediciones bien fuera del período de gracia (sin efecto)
  • Complementos: 50 complementos instalados (complementos oficiales estándar)
  • Sin modificaciones del núcleo: Instalación limpia de Discourse
  • Entorno: Ambos entornos de prueba son implementaciones idénticas de Azure AKS

Evidencia clave

Hallazgo más importante:

Teníamos un entorno de DESARROLLO funcional en una compilación anterior. Después de actualizar a latest-release +122, la automatización dejó de funcionar. Esto demuestra con certeza que se introdujo una regresión en las compilaciones recientes.

Ambos entornos ahora exhiben un comportamiento roto idéntico después de estar en la misma versión.


Reproducibilidad

100% reproducible - probado en dos entornos independientes:

  1. Instalar Discourse latest-release (release +122)
  2. Crear automatización con el disparador post_created_edited
  3. Editar una publicación
  4. Observar que la automatización nunca se activa
  5. Confirmar que el evento :post_edited nunca se activa utilizando el escuchador de prueba

Resumen

Este es una regresión confirmada en latest-release (release +122). El evento :post_edited funcionaba en versiones anteriores y dejó de funcionar después de la actualización. Dos entornos independientes confirmaron el mismo comportamiento. Esto rompe la funcionalidad principal de Automatización de Discourse y todos los complementos que dependen de los eventos de edición de publicaciones.

1 me gusta

Así no es como funciona DiscourseEvent: no es entre procesos, sino dentro del mismo proceso. Por lo tanto, los eventos solo son capturados por los oyentes en el mismo proceso que desencadenó el evento.

En el caso de la automatización de Discourse, acabo de probarlo localmente con la siguiente configuración

y edité una publicación y envió el mensaje de chat con éxito

1 me gusta

¡Gracias! Volveré a revisar esto, ya que claramente lo he entendido mal. Espero poder hacer funcionar mi complemento con esta información. Muy apreciado,

Gracias @zogstrip; también probamos observando los registros de producción mientras editábamos a través de la interfaz web:

Procedimiento de prueba:

  1. Se borró el enfriamiento de la automatización a través de la consola
  2. Se observaron los registros: tail -f /var/www/discourse/log/production.log | grep "PDF Automation"
  3. Se editó una publicación a través del navegador web (mismo proceso que la automatización)
  4. Resultado: La edición se completa con éxito (200 OK), pero la automatización nunca se activa

Tenemos dos entornos idénticos (DEV y PROD en Azure AKS):

  • Antes de la actualización: La automatización de DEV funcionaba perfectamente (aparecen entradas en el archivo de registro)
  • Después de actualizar a latest-release (+122): Las automatizaciones de DEV y PROD dejaron de funcionar
  • Probado a través de la interfaz web: Todavía no se activa ninguna automatización

Nuestra configuración de automatización:

  • Disparador: post_created_edited
  • Script: Scriptable personalizado (run_pdf_generation)
  • Filtro: ID de categoría 34, etiqueta “hd96-24”

¿Podría haber algo específico sobre los scriptables personalizados o nuestro entorno que esté impidiendo que se active la automatización? El hecho de que funcionara antes de la actualización sugiere que algo cambió en cómo se disparan los eventos post_created_edited.

¿Podrías intentar con una automatización “más sencilla” que use el mismo disparador? ¿Hay algo potencialmente relacionado en /logs?

1 me gusta

Buena idea. Crearé un ejemplo básico para reproducir el problema y te lo enviaré el lunes. ¡Que tengas un buen fin de semana! :slight_smile:

Tenías toda la razón sobre el problema entre procesos con DiscourseEvent, ¡gracias por esa aclaración!

Después de tus comentarios, probamos correctamente con una automatización simple de send_chat_message usando el mismo disparador post_created_edited. Cuando editamos una publicación, la automatización SÍ se activó (la vimos procesándose en los registros y obtuvimos un error 500 debido a la mala configuración de los ajustes de chat, no al disparador en sí).

Esto confirma: El disparador post_created_edited funciona correctamente.

Nuestra confusión provino de:

  1. Probar con un oyente de consola de Rails (incorrecto, entre procesos)
  2. Nuestro script personalizado de PDF se perdió durante una reconstrucción y tuvimos problemas para volver a registrarlo de forma persistente

El mecanismo del disparador en sí está funcionando como se esperaba. ¡Disculpa la confusión y gracias por la ayuda!

Me alegra que todo funcione como se esperaba :+1:

Ahora la parte difícil, encontrar la causa raíz de por qué tu script personalizado run_pdf_generation ya no funciona :sweat_smile:

1 me gusta