Was würde dazu führen, dass einige Beiträge nicht im Mailinglistenmodus versendet werden

Unterstützung
1

Auf einer aktuellen selbst gehosteten Version von Discourse werden bei einigen Themen die Beiträge nicht an alle Benutzer gesendet, die sich für den Erhalt aller Beiträge im E-Mail-Listenmodus angemeldet haben.

Ich habe meine E-Mail-Protokolle überprüft, es werden definitiv E-Mails für Beiträge in diesem Thema an einige Benutzer gesendet, aber nicht an andere, die sich ebenfalls für den Erhalt von E-Mails für alle Beiträge angemeldet haben. Eines meiner Testbenutzerkonten erhält sie, ein anderes Testbenutzerkonto jedoch nicht.

Ich habe versucht, mehrmals in das Thema zu posten, und das hat auch mindestens eine andere Person getan.

Ich sehe keine Website- oder Benutzereinstellungen, die dies verursachen könnten. Was übersehe ich?

Dies sind die Beiträge:

  id   | user_id |          timezone
--------+---------+----------------------------
 119197 |     586 | 2023-04-03 11:05:41
 119198 |       2 | 2023-04-03 11:12:03.207053
 119215 |       2 | 2023-04-03 15:42:45.195223
 119216 |       2 | 2023-04-03 16:18:22.664227
 119218 |     508 | 2023-04-03 16:55:42.167977
 119219 |       2 | 2023-04-03 16:56:00.140777
 119222 |       2 | 2023-04-03 18:11:33.953314
(7 rows)

Dies sind die E-Mails, die an Benutzer 703 gesendet wurden (aus der Tabelle email_logs):

 id  | post_id |  email_type  |          timezone          |      smtp_transaction_response
-----+---------+--------------+----------------------------+--------------------------------------
 242 |  119197 | mailing_list | 2023-04-03 11:18:55.832126 | 250 2.0.0 Ok: queued as C95C443350B8
 243 |  119198 | mailing_list | 2023-04-03 11:22:04.731579 | 250 2.0.0 Ok: queued as B0E2943350B8
(2 rows)

Dies sind alle E-Mails, die für diese Beiträge gesendet wurden:

 id  | post_id |  email_type  | user_id |          timezone          |      smtp_transaction_response
-----+---------+--------------+---------+----------------------------+--------------------------------------
 242 |  119197 | mailing_list |     703 | 2023-04-03 11:18:55.832126 | 250 2.0.0 Ok: queued as C95C443350B8
 243 |  119198 | mailing_list |     703 | 2023-04-03 11:22:04.731579 | 250 2.0.0 Ok: queued as B0E2943350B8
 276 |  119215 | mailing_list |       5 | 2023-04-03 15:52:47.834189 | 250 2.0.0 Ok: queued as B51B443350B8
 277 |  119216 | mailing_list |       5 | 2023-04-03 16:28:29.651872 | 250 2.0.0 Ok: queued as 8760743350B8
 281 |  119218 | mailing_list |       5 | 2023-04-03 17:05:43.582886 | 250 2.0.0 Ok: queued as 8209143350B8
 282 |  119219 | mailing_list |       5 | 2023-04-03 17:06:02.231359 | 250 2.0.0 Ok: queued as 201A243350B8
 287 |  119222 | user_replied |     508 | 2023-04-03 18:21:38.024441 | 250 2.0.0 Ok: queued as EDE47434362C
 288 |  119222 | mailing_list |       5 | 2023-04-03 18:21:38.074723 | 250 2.0.0 Ok: queued as 07474434362D
(8 rows)

Benutzer-ID 5 wurde erst zur Liste der kopierten Benutzer hinzugefügt, als ich das Problem in einem anderen Thema bemerkte.

Dies scheint bei fast der Hälfte der heute erstellten Themen/Beiträge zu passieren. Dieses System ist erst gestern live gegangen, aber ich habe während der Tests nichts dergleichen gesehen.

2

Ich habe versucht, die maximale Anzahl von E-Mails pro Benutzer und Tag auf 0 zu setzen, um sie zu deaktivieren. Zuvor lag der Wert bei 100, was er anscheinend nicht erreicht hätte.

Update: Das hat das Problem nicht behoben.

Sollte nicht irgendwo ein Grund dafür protokolliert werden, warum die E-Mail nicht gesendet wird?

3

Ja: Einstellungen → Protokolle → Fehlerprotokolle

4

Nichts im Fehlerprotok darüber, noch etwas in der Nähe der Zeitstempel, zu denen die fehlenden E-Mails hätten gesendet werden sollen.

Könnte dies ein Sidekiq-Problem sein? Ich habe heute viele Meldungen, dass Sidekiq zu viel Speicher verbraucht.

5

Es scheint, dass das Thema durcheinandergerät. Sobald ein Beitrag in diesem Thema nicht an diesen Benutzer gesendet wird, werden auch keine zukünftigen Beiträge an diesen Benutzer gesendet.

6

Es scheint, dass topic_user.notification_level für diesen Benutzer/dieses Thema auf 0 (stummgeschaltet?) gesetzt wurde, und es scheint keine Möglichkeit zu geben, es über die Admin-Bildschirme wieder auf 1 zu setzen, obwohl dies wahrscheinlich mit Rails geschehen kann. Aber wie wurde es geändert?

Könnte dies das Ergebnis davon gewesen sein, dass jemand auf den ‘Abmelden’-Link in der E-Mail geklickt hat, bevor ich herausgefunden habe, wie ich ihn von den E-Mails, die an den Relay-Server gesendet werden, unterdrücken kann? Wenn ja, sollte es dann nicht eine Möglichkeit geben, dies rückgängig zu machen?

7

Das Entfernen aller Tags in den beiden betroffenen Themen oder das Einstellen der Benachrichtigung auf etwas anderes als „stummgeschaltet“ scheint die topic_users nicht geändert zu haben.

In den stummgeschalteten Themen im Profil dieses Benutzers wird nichts angezeigt.

Ich bin mir nicht sicher, ob ich alle Themen einfach per Massenänderung ändern möchte. Hier ist die Anzahl der Werte von notification_level in topic_users:

 notification_level | count
--------------------+--------
                  0 |      2
                  1 |    177
                  2 |     45
                  3 | 119818
8

Hurra, ich habe endlich herausgefunden, wie ich diese Themen für diesen Benutzer stummschalten kann!

Ich musste feststellen, dass sich in der linken Spalte der Tracking-Seite für diesen Benutzer über dem stummgeschalteten Feld ein ‘show’-Tag befand.

9

Haben sie dieses Thema nicht absichtlich stummgeschaltet und möchten keine Benachrichtigungen/E-Mails dazu erhalten?

10

Nein, da es sich im Wesentlichen um ein Mitarbeiterkonto handelte, das ich zu dem Zweck eingerichtet hatte, Beiträge von einer Gruppe an eine externe Legacy-Mailingliste weiterzuleiten, und soweit ich weiß, habe ich diesen Benutzer zu diesem Thema nie absichtlich stummgeschaltet.

Aber zumindest habe ich viel über die Datenstruktur gelernt, einige Ruby-Codes durchgelesen und ein paar Dinge über die Admin-Rolle gelernt. :zwinker:

Ich denke, dieses Thema kann jetzt geschlossen werden.