Mögliches post_edited Event Regressionsproblem?

Discourse-Fehlerbericht: :post_edited-Ereignisregression in latest-release

Betrifft: Discourse latest-release-Branch (Release +122)
Status: Bestätigte Regression – reproduzierbar
Datum: 15. Januar 2026


Zusammenfassung

Das DiscourseEvent :post_edited wird in neueren latest-release-Builds nicht mehr veröffentlicht. Beitragsbearbeitungen werden erfolgreich abgeschlossen und Revisionen erstellt, aber das Ereignis, auf das Plugins angewiesen sind, wird nie ausgelöst. Dies führt dazu, dass alle Plugins, die den Automatisierungstrigger post_created_edited verwenden, und alle anderen Plugins, die auf :post_edited-Ereignisse lauschen, fehlschlagen.


Reproduktion (Bestätigt)

Wir haben die Regression bestätigt, indem wir sie in zwei identischen Azure AKS-Umgebungen getestet haben:

Vor dem Update (Funktioniert)

  • Version: v2026.1.0-latest (älterer Build)
  • Verhalten: :white_check_mark: :post_edited-Ereignisse werden korrekt ausgelöst
  • Automatisierung: :white_check_mark: Funktioniert automatisch

Nach dem Update (Defekt)

  • Version: latest-release +1221 hours ago, release +122
  • Verhalten: :cross_mark: :post_edited-Ereignisse werden nie ausgelöst
  • Automatisierung: :cross_mark: Vollständig defekt

Kritischer Befund: Beide Umgebungen funktionierten vor dem Update. Beide sind nach dem Update auf latest-release +122 ausgefallen. Dies beweist eindeutig, dass eine Regression eingeführt wurde.


Umgebungsdetails

  • Discourse Version: latest-release (Release +122)
  • Rails Version: 8.0.4
  • Infrastruktur: Azure Kubernetes Service (AKS)
  • Docker Image: discourse/base:2.0.20260109-0020
  • Bereitstellung: Standardmäßige Discourse Docker-Installation

Testverfahren

Test 1: Ereignis-Listener (Beweist, dass das Ereignis nie ausgelöst wird)

# In der Rails-Konsole
File.open('/tmp/post_edited_test.log', 'w') { |f| f.write("Test gestartet um #{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 ausgelöst! Beitrag #{post.id}\n")
  end
end

Bearbeiten Sie dann einen beliebigen Beitrag über die Weboberfläche und überprüfen Sie:

cat /tmp/post_edited_test.log

Ergebnis bei latest-release +122: Zeigt nur „Test gestartet“ – das Ereignis wird nie ausgelöst
Ergebnis beim älteren Build: Zeigt Ereigniseinträge mit Zeitstempeln und Beitrags-IDs

Test 2: Überprüfung der Erstellung von Revisionen

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

Ergebnis: Revisionen WERDEN korrekt mit den entsprechenden Zeitstempeln erstellt
Schlussfolgerung: Bearbeitungen werden erfolgreich verarbeitet, aber post_process_post wird nicht aufgerufen oder das Ereignis wird nicht ausgelöst

Test 3: Manuelle Ereignisauslösung (Beweist, dass das Ereignissystem funktioniert)

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

Ergebnis: Ereignishandler werden korrekt ausgeführt
Schlussfolgerung: Das Ereignissystem funktioniert, aber die automatische Auslösung bei Bearbeitungen ist defekt


Erwartetes Verhalten

Wenn ein Beitrag über die Weboberfläche bearbeitet wird:

  1. Bearbeitung wird erfolgreich gespeichert :white_check_mark:
  2. Beitragsrevision erstellt :white_check_mark:
  3. PostRevisor#post_process_post wird aufgerufen :cross_mark:
  4. :post_edited-Ereignis ausgelöst :cross_mark:
  5. Ereignishandler werden ausgeführt :cross_mark:

Nur die Schritte 1-2 funktionieren. Die Schritte 3-5 sind defekt.


Tatsächliches Verhalten

Die Produktionsprotokolle zeigen einen erfolgreichen Abschluss der Bearbeitung:

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

Keine Fehler, keine Ausnahmen, aber kein :post_edited-Ereignis veröffentlicht.

Das Ereignis sollte in /var/www/discourse/lib/post_revisor.rb Zeile 759 ausgelöst werden:

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

Diese Methode wird ab Zeile 341 aufgerufen, aber das Ereignis wird nicht ausgelöst.


Auswirkungen

Betroffene offizielle Funktionen

  • Discourse Automation: Der Trigger post_created_edited ist vollständig defekt
  • Alle Automatisierungs-Workflows, die von Beitragsbearbeitungen abhängen, schlagen fehl

Betroffene Plugins

Alle Plugins, die auf :post_edited-Ereignisse lauschen, sind defekt:

  • discourse-automation – Offizielle Automatisierungstrigger
  • discourse-ai – KI-Moderation bei bearbeiteten Beiträgen
  • discourse-doc-categories – Aktualisierungen des Dokumentationsindex
  • discourse-topic-voting – Workflows zum Zurückziehen von Stimmen
  • Alle benutzerdefinierten Plugins, die Beitragsbearbeitungsereignisse verwenden

Regressions-Zeitachse

  1. Älterer Build: v2026.1.0-latest:post_edited-Ereignisse funktionierten :white_check_mark:
  2. Update auf: latest-release (Release +122) – :post_edited-Ereignisse defekt :cross_mark:
  3. Bestätigt auf: Zwei unabhängigen Produktionsumgebungen (beide sind nach dem Update ausgefallen)

Dies beweist eindeutig, dass in neueren latest-release-Builds eine Regression eingeführt wurde.


Workaround

Manuelles Auslösen über die Rails-Konsole funktioniert:

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

Dies bestätigt, dass das Automatisierungssystem selbst funktioniert – nur die automatische Ereignisauslösung ist defekt.


Konfigurationshinweise

  • Einstellungen überprüft: Alle bearbeitungsbezogenen Einstellungen sind Standard/Standard
  • Gnadenfrist: Tests mit Bearbeitungen weit außerhalb der Gnadenfrist durchgeführt (keine Auswirkung)
  • Plugins: 50 Plugins installiert (Standard-Offiziell-Plugins)
  • Keine Kernmodifikationen: Saubere Discourse-Installation
  • Umgebung: Beide Testumgebungen sind identische Azure AKS-Bereitstellungen

Wichtigste Beweise

Wichtigster Befund:

Wir hatten eine funktionierende DEV-Umgebung mit einem älteren Build. Nach dem Update auf latest-release +122 funktionierte die Automatisierung nicht mehr. Dies beweist mit Sicherheit, dass in den letzten Releases eine Regression eingeführt wurde.

Beide Umgebungen weisen nun nach der gleichen Version das identische fehlerhafte Verhalten auf.


Reproduzierbarkeit

100% reproduzierbar – getestet auf zwei unabhängigen Umgebungen:

  1. Installieren Sie Discourse latest-release (Release +122)
  2. Erstellen Sie eine Automatisierung mit dem Trigger post_created_edited
  3. Bearbeiten Sie einen Beitrag
  4. Beobachten Sie, dass die Automatisierung nie ausgelöst wird
  5. Bestätigen Sie, dass das :post_edited-Ereignis nie ausgelöst wird, indem Sie den Test-Listener verwenden

Zusammenfassung

Dies ist eine bestätigte Regression in latest-release (Release +122). Das :post_edited-Ereignis funktionierte in früheren Versionen und funktioniert nach dem Update nicht mehr. Zwei unabhängige Umgebungen bestätigten das gleiche Verhalten. Dies unterbricht die Kernfunktionalität von Discourse Automation und alle Plugins, die von Beitragsbearbeitungsereignissen abhängen.

1 „Gefällt mir“

So funktioniert DiscourseEvent nicht – es ist nicht prozessübergreifend, sondern innerhalb eines Prozesses. Die Ereignisse werden also nur von Listenern im selben Prozess erfasst, der sie ausgelöst hat.

Im Falle der Discourse-Automatisierung habe ich es gerade lokal mit den folgenden Einstellungen getestet:

und einen Beitrag bearbeitet, und es wurde erfolgreich die Chat-Nachricht gesendet

1 „Gefällt mir“

Danke! Ich werde das noch einmal überprüfen, da ich es offensichtlich falsch verstanden habe. Hoffentlich kann ich mein Plugin mit diesen Informationen zum Laufen bringen. Sehr geschätzt,

Danke @zogstrip – wir haben auch getestet, indem wir die Produktionsprotokolle beobachtet haben, während wir über die Weboberfläche bearbeitet haben:

Testverfahren:

  1. Automatisierungs-Cooldown über die Konsole gelöscht
  2. Protokolle beobachtet: tail -f /var/www/discourse/log/production.log | grep "PDF Automation"
  3. Beitrag über den Webbrowser bearbeitet (gleicher Prozess wie bei der Automatisierung)
  4. Ergebnis: Bearbeitung erfolgreich abgeschlossen (200 OK), aber die Automatisierung wird nie ausgelöst

Wir haben zwei identische Umgebungen (DEV und PROD auf Azure AKS):

  • Vor dem Update: DEV-Automatisierung funktionierte einwandfrei (Einträge in der Protokolldatei erscheinen)
  • Nach dem Update auf latest-release (+122): Beide DEV- und PROD-Automatisierungen funktionierten nicht mehr
  • Über die Weboberfläche getestet: Immer noch keine Auslösung der Automatisierung

Unsere Automatisierungskonfiguration:

  • Auslöser: post_created_edited
  • Skript: Benutzerdefiniertes Skript (run_pdf_generation)
  • Filter: Kategorie-ID 34, Tag „hd96-24“

Könnte es etwas Spezifisches an benutzerdefinierten Skripten oder unserer Umgebung geben, das verhindert, dass die Automatisierung ausgelöst wird? Die Tatsache, dass es vor dem Update funktionierte, deutet darauf hin, dass sich etwas geändert hat, wie post_created_edited-Trigger ausgelöst werden.

Könnten Sie es mit einer „einfacheren“ Automatisierung versuchen, die denselben Auslöser verwendet? Gibt es etwas potenziell Relevantes in /logs?

1 „Gefällt mir“

Gute Idee – ich werde ein einfaches Beispiel erstellen, um das Problem zu reproduzieren, und es Ihnen am Montag zusenden. Schönes Wochenende :slight_smile:

Sie hatten absolut Recht bezüglich des Inter-Prozess-Problems mit DiscourseEvent – vielen Dank für diese Klarstellung!

Nach Ihrem Feedback haben wir mit einer einfachen send_chat_message-Automatisierung unter Verwendung desselben post_created_edited-Triggers ordnungsgemäß getestet. Als wir einen Beitrag bearbeitet haben, hat der Automatisierungsprozess ausgelöst (wir sahen ihn in den Protokollen verarbeiten und erhielten einen 500-Fehler aufgrund einer Fehlkonfiguration der Chat-Einstellungen, nicht wegen des Triggers selbst).

Dies bestätigt: Der post_created_edited-Trigger funktioniert korrekt.

Unsere Verwirrung entstand durch:

  1. Testen mit einem Rails-Konsolen-Listener (falsch – Inter-Prozess)
  2. Unser benutzerdefiniertes PDF-Skript ging während eines Rebuilds verloren und wir hatten Schwierigkeiten, es dauerhaft neu zu registrieren

Der Trigger-Mechanismus selbst funktioniert wie erwartet. Entschuldigung für die Verwirrung und vielen Dank für die Hilfe!

Schön, dass alles wie erwartet funktioniert :+1:

Nun der schwierige Teil, die Ursache dafür zu finden, warum Ihr benutzerdefiniertes run_pdf_generation-Skript nicht mehr funktioniert :sweat_smile:

1 „Gefällt mir“