Digest-E-Mails werden nicht an Benutzer gesendet, obwohl alle Bedingungen erfüllt sind (Discourse 3.6)

Wir verwenden Discourse 3.6 und stellen fest, dass einige Benutzer, die Digest-E-Mails erhalten sollten, diese nie erhalten.

Hier ist, was wir für den betroffenen Benutzer bestätigt haben:

  • enable_digest_emails ist true

  • Der Benutzer war lange genug inaktiv, um einen Digest auszulösen

  • Die E-Mail ist gültig und bestätigt

  • Kein Bounces oder Unterdrückungen vom Mailprovider

  • Andere E-Mails (Benachrichtigungen usw.) werden problemlos gesendet

  • Im Protokoll Admin → E-Mails → Gesendet wird keine Digest-E-Mail angezeigt

  • Bei Verwendung von Admin → E-Mails → Digest-Test zeigt das System korrekt „Ja, ein Digest sollte gesendet werden“ an – aber es wird tatsächlich nichts gesendet oder protokolliert.

Es treten keine verwandten Fehler in den Sidekiq- oder Produktionsprotokollen auf.

Haben andere Benutzer Digest-E-Mails unter 3.6 stillschweigend fehlschlagen sehen, auch wenn alle Einstellungen und Berechtigungsprüfungen in der Admin-Oberfläche darauf hindeuten, dass der Benutzer eine erhalten sollte?

2 „Gefällt mir“

Haben Sie die Einstellungen des Benutzers im Reiter „E-Mail“ seiner Präferenzen überprüft?

Ja, hier ist ihre Einstellung, und hier ist die Digest-Darstellung, die uns sagt, dass sie gesendet werden soll.

Update / Repro Steps (Discourse 3.6)

Ich habe dies mit der Rails-Konsole explizit reproduziert, um zu bestätigen, was auf Job-Ebene passiert. Hier ist, was wir für den betroffenen Benutzer sehen:

site: hvac

now: 2025-10-15 17:23:01 UTC

disable_emails: “no”

disable_digest_emails: false

default_email_digest_frequency_minutes: 10080

ENV_DISABLE_EMAILS: nil

perform_deliveries: nil

smtp_address: “smtp.netcorecloud.net

smtp_port: 587

– USER –

id: 42122

username: milnerlarry

active: true

suspended: false

email_digests: true

digest_after_minutes: 10080

eligible_by_time: true

– LAST 15 EMAIL LOGS –

2025-10-01 | type=digest | bounced=false

2025-09-22 | type=digest | bounced=false

perform_deliveries_now: true

Wenn ich dann den Digest manuell erzwinge, denkt Discourse, dass es ihn erstellt, gibt aber Folgendes zurück:

mail = UserNotifications.digest(u)

=> Built digest mail: subject=nil bytes=50

Discourse denkt also, dass es den Digest erstellt, aber er ist tatsächlich leer (subject=nil) – und wird daher beim Ausführen des Jobs stillschweigend übersprungen. Es wird kein EmailLog-Eintrag erstellt und nichts gesendet.

Dies bestätigt:

  • Der Job wird erfolgreich eingereiht

  • SMTP und Zustellungen sind aktiviert

  • Der Digest-Job wird ohne Fehler beendet, da der Mailer einen leeren Digest zurückgibt

Das Ausführen des Jobs inline mit:

Jobs::UserEmail.new.execute(“type” => “digest”, “user_id” => u.id”)

liefert das gleiche Ergebnis – es wird keine neue EmailLog-Zeile erstellt.

Mögliche Ursache:

Es scheint, dass der Digest aufgrund einer Bedingung „leerer Digest“ übersprungen wird – vielleicht hat sich in Discourse 3.6 etwas daran geändert, wie Inhalte für die Aufnahme bewertet werden. Die Ansicht Admin → E-Mails → Digest-Test rendert den Digest korrekt, aber der Hintergrundjob sieht nichts, was enthalten werden soll.

Zusammenfassung:

:white_check_mark: Berechtigter Benutzer

:white_check_mark: Aktive E-Mail + gültiges SMTP

:white_check_mark: Admin Digest Test rendert ordnungsgemäß

:prohibited: Hintergrund-Digest-Job überspringt stillschweigend (leerer Digest)

:prohibited: Kein EmailLog oder Sendeversuch aufgezeichnet

Ich würde mich über eine Bestätigung vom Team freuen – gibt es möglicherweise eine Regression in der Art und Weise, wie UserNotifications.digest Inhalte in 3.6 sammelt?

Hier wird noch etwas mehr Arbeit geleistet, wir haben eine Handvoll (von 4.000) Benutzern gefunden, die tatsächlich zuverlässig Aktivitätszusammenfassungen erhalten.

Wenn man einen dieser Benutzer, der Zusammenfassungen erhält, mit einem vergleicht, der dies nicht tut, gibt es keinen Unterschied in ihren Einstellungen.

===== xxxxx (ID: 4149) =====
Aktiv: true, Gesperrt: false, Stummgeschaltet: false
E-Mail bestätigt: false
Digest aktiviert: true
Digest-Häufigkeit: 10080 Minuten
Zuletzt gesehen: 2025-03-24 20:58:55 UTC
Zuletzt E-Mail gesendet: 2025-10-16 17:07:53 UTC
Stummgeschaltete Kategorien:
Benutzerstatistiken Digest versucht: 2025-10-16 17:07:53 UTC
Gesamte gesendete E-Mails: 16
===== xxxxxxx (ID: 42206) =====
Aktiv: true, Gesperrt: false, Stummgeschaltet: false
E-Mail bestätigt: false
Digest aktiviert: true
Digest-Häufigkeit: 10080 Minuten
Zuletzt gesehen: 2025-09-14 15:52:54 UTC
Zuletzt E-Mail gesendet: 2025-10-01 23:30:33 UTC
Stummgeschaltete Kategorien:
Benutzerstatistiken Digest versucht: 2025-10-16 17:32:34 UTC
Gesamte gesendete E-Mails: 2

Sicherlich gibt es andere Einstellungen, aber ich fand dies auf jeden Fall einen interessanten Vergleich.

Kann jemand einen Rails-Befehl bereitstellen, den wir ausführen können, um zu überprüfen, wie viele Digests / Aktivitätszusammenfassungen wirklich überfällig sind? Im Wesentlichen eine Integritätsprüfung, ob das System die Zusammenfassungen wie vorgesehen sendet.

Sie können die folgende Rails-Konsolenabfrage ausprobieren: die aktiven Benutzer, die E-Mail- Digests aktiviert haben und für ihre nächste Digest-E-Mail fällig sind

User.joins(:user_option)
  .where("user_options.email_digests = ?", true)
  .where("users.suspended_at IS NULL")
  .where("COALESCE(users.last_emailed_at, users.created_at) < (NOW() - INTERVAL '1 minute' * user_options.digest_after_minutes)")
  .count

Ist es möglich, dass die Zusammenfassung übersprungen wird, weil der Benutzer nicht für E-Mail-Zusammenfassung nach Tagen unterdrücken besucht hat?

@jahan_gagan das ist nützlich, aber das wird uns sagen, wer eine Zusammenfassung/Aktivitätsübersicht erhält, aber nicht, wer seine Aktivitätsübersicht NICHT erhalten hat. Macht das Sinn? Die Frage ist, wie wir sehen können, wer die Zusammenfassung NICHT erhält, die er erhalten sollte.

@Moin wir haben es auf 0 gesetzt – das sollte kein Faktor sein.

Sind Sie sicher, dass 0 das deaktiviert? Haben Sie stattdessen eine große Zahl versucht?

@Moin Danke, habe es auf 3000 geändert – keine Änderung bei der gesendeten Zusammenfassung. Ich sehe immer noch Hunderte mit wöchentlicher Frequenz (jetzt über zwei Wochen), ohne dass sie gesendet werden.

Okay, hier ist ein Test, um zu sehen, wer gerade berechtigt ist:

Wir werden jetzt einen Sendevorgang erzwingen, und es wird nichts gesendet…

Wir nehmen einen Beispielbenutzer, der den Digest nicht erhält, und überprüfen die Admin-Oberfläche, und er scheint vollständig berechtigt zu sein…

Okay, mangels anderer Ideen haben wir die Häufigkeit der Digests für alle Benutzer über den Admin auf täglich (1440) umgestellt.

Und plötzlich wurden alle Digests versendet…

Hat irgendjemand eine Idee, warum das so ist? Die Änderung der Häufigkeit sollte keine Auswirkungen haben, da wir sehen können, dass diese Benutzer für die wöchentliche Häufigkeit berechtigt waren.

Ich habe zu früh gesprochen, die Änderung der Frequenz hat für eine Benutzergruppe (einen Standort) funktioniert, aber für eine andere hat sie nichts bewirkt. Das Rätsel geht weiter…

Ich glaube, es könnte an einer der letzten Anforderungen in der von mir oben verlinkten Abfrage liegen.

Nachdem überprüft wurde, ob der Benutzer echt, aktiviert, nicht inszeniert und nicht gesperrt ist, und nachdem überprüft wurde, ob er die Benachrichtigungen nicht deaktiviert hat und die Frequenz größer als 0 ist, eine primäre E-Mail vorhanden ist und der Bounce-Score in Ordnung ist, gibt es einige zeitbasierte Prüfungen:

Zuletzt gesehen vor mehr als digest_after_minutes Minuten
Zuletzt gesehen innerhalb von suppress_digest_email_after_days Tagen
Die letzte Prüfung, ob der Benutzer eine Zusammenfassung erhalten sollte, fand vor digest_after_minutes Minuten statt.

Ich denke, letzteres könnte die Ursache sein. Wenn Discourse versucht hat, die Zusammenfassung gestern zu senden, und digest_after_minutes eine Woche ist, dann wird es erst in einer Woche erneut versucht. Wenn Sie diesen Wert reduzieren, geschieht der nächste Versuch früher.

1 „Gefällt mir“

@Jacob_Peebles sieht so aus, als hättest du damit schon eine ganze Weile zu kämpfen! Ich glaube, Digest Emails Not Sending to All Users – Need Help Debugging im März handelt vom selben Problem, habe ich Recht?

Hat Moin’s letzter Beitrag geholfen? Wenn ja, lass es uns wissen, damit wir dieses Thema abschließen können.