Email riassuntive non inviate per gli utenti anche se tutte le condizioni sono soddisfatte (Discourse 3.6)

[Jacob_Peebles]

Siamo su Discourse 3.6 e stiamo riscontrando un problema per cui alcuni utenti che dovrebbero ricevere le email digest non le ricevono mai.

Ecco cosa abbiamo confermato per l’utente interessato:

• enable_digest_emails è true
• L’utente è stato inattivo abbastanza a lungo da attivare un digest
• L’email è valida e confermata
• Nessun rimbalzo o soppressione da parte del provider di posta
• Altre email (notifiche, ecc.) vengono inviate correttamente
• Nessuna email digest viene visualizzata nel log Admin → Emails → Sent
• Quando si utilizza Admin → Emails → Digest Test, il sistema mostra correttamente “Sì, un digest dovrebbe essere inviato”, ma nulla viene effettivamente inviato o registrato.

Non compaiono errori correlati nei log di Sidekiq o di produzione.

Qualcun altro ha riscontrato un mancato invio silenzioso delle email digest su 3.6 anche quando tutte le impostazioni e i controlli di idoneità nell’interfaccia di amministrazione indicano che l’utente dovrebbe riceverne una?

[Lilly (Lillian Louis)]

Hai controllato le impostazioni dell’utente nella scheda email delle preferenze?

[Jacob_Peebles]

Sì, ecco le loro impostazioni e qui c’è il rendering digest per loro che ci dice che dovrebbe essere inviato.

[Jacob_Peebles]

Aggiornamento / Passaggi di Riproduzione (Discourse 3.6)

Ho eseguito una riproduzione esplicita di questo problema utilizzando la console Rails per confermare cosa sta succedendo a livello di job. Ecco cosa vediamo per l’utente interessato:

sito: hvac

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

disabilita_email: “no”

disabilita_email_digest: false

frequenza_minuti_digest_email_predefinita: 10080

ENV_DISABILITA_EMAIL: nil

esegui_consegne: nil

indirizzo_smtp: “smtp.netcorecloud.net”

porta_smtp: 587

– UTENTE –

id: 42122

username: milnerlarry

attivo: true

sospeso: false

email_digest: true

minuti_ammissibili_per_tempo: 10080

– ULTIMI 15 LOG EMAIL –

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

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

esegui_consegne_ora: true

Quindi, quando ho forzato la creazione manuale del digest, Discourse pensa di crearlo ma restituisce:

mail = UserNotifications.digest(u)

=> Mail digest creata: subject=nil bytes=50

Quindi Discourse pensa di creare il digest, ma in realtà è vuoto (subject=nil) — e quindi viene silenziosamente saltato quando il job viene eseguito. Non viene creata alcuna voce in EmailLog e non viene inviato nulla.

Questo conferma:

• Il job viene accodato con successo
• SMTP e le consegne sono abilitati
• Il job di digest termina senza errori perché il mailer restituisce un digest vuoto

L’esecuzione del job inline con:

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

produce lo stesso risultato — nessuna nuova riga in EmailLog creata.

Possibile Causa:

Sembra che il digest venga saltato a causa di una condizione di “digest vuoto” — forse qualcosa è cambiato nel modo in cui Discourse 3.6 valuta il contenuto da includere. La visualizzazione Admin → Emails → Digest Test visualizza correttamente il digest, ma il job in background non vede nulla da includere.

Riepilogo:

Utente idoneo

Email attiva + SMTP valido

Admin Digest Test viene visualizzato correttamente

Job di digest in background saltato silenziosamente (digest vuoto)

Nessun tentativo di registrazione o invio di EmailLog registrato

Mi piacerebbe una conferma dal team — c’è forse una regressione nel modo in cui UserNotifications.digest raccoglie il contenuto in 3.6?

[Jacob_Peebles]

Stiamo facendo un po’ più di lavoro qui, abbiamo trovato una manciata (su 4k) di utenti che ricevono in modo affidabile i riepiloghi delle attività.

Confrontando uno di questi utenti che riceve i riepiloghi con uno che non li riceve, non mostra alcuna differenza nelle loro impostazioni.

===== xxxxx (ID: 4149) =====
Attivo: true, Sospeso: false, Silenziato: false
Email confermata: false
Digest abilitato: true
Frequenza digest: 10080 minuti
Ultimo accesso: 2025-03-24 20:58:55 UTC
Ultima email inviata: 2025-10-16 17:07:53 UTC
Categorie silenziate:
Digest statistiche utente tentato: 2025-10-16 17:07:53 UTC
Email totali inviate: 16
===== xxxxxxx (ID: 42206) =====
Attivo: true, Sospeso: false, Silenziato: false
Email confermata: false
Digest abilitato: true
Frequenza digest: 10080 minuti
Ultimo accesso: 2025-09-14 15:52:54 UTC
Ultima email inviata: 2025-10-01 23:30:33 UTC
Categorie silenziate:
Digest statistiche utente tentato: 2025-10-16 17:32:34 UTC
Email totali inviate: 2

Certamente ci sono altre impostazioni, ma ho pensato che questo fosse comunque un confronto interessante.

[Jacob_Peebles]

Qualcuno può fornire un comando rails che possiamo eseguire per verificare quanti digest / riepiloghi di attività sono veramente in ritardo? Essenzialmente un controllo di integrità che il sistema stia effettivamente inviando i riepiloghi come previsto.

[jahan_gagan]

Puoi provare la seguente query della console Rails, gli utenti attivi che hanno abilitato i digest via email e sono dovuti per la loro prossima email di digest

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

[Moin]

È possibile che il riepilogo venga saltato perché l’utente non ha visitato per Sopprimi email di riepilogo dopo giorni?

[Jacob_Peebles]

@jahan_gagan è utile, ma ci dirà chi riceverà un riepilogo/sommario delle attività, ma non chi NON ha ricevuto il proprio riepilogo delle attività. Ha senso? La domanda è come vediamo chi NON sta ricevendo il riepilogo che dovrebbe.

[Jacob_Peebles]

@Moin lo abbiamo impostato su 0 - questo non dovrebbe essere un fattore.

[Moin]

Sei sicuro che 0 disabiliti questo? Hai provato invece un numero grande?

app/jobs/scheduled/enqueue_digest_emails.rb

[Jacob_Peebles]

@Moin Grazie, l’ho cambiato in 3000 - nessuna modifica nell’invio del digest. Vedo ancora centinaia con frequenza settimanale (ora oltre due settimane) senza essere inviate.

[Jacob_Peebles]

Va bene, ecco un test per vedere chi è idoneo in questo momento:

Forzeremo un invio ora, e non viene inviato nulla…

Prendendo un utente di esempio che non riceve il digest, e controllando l’interfaccia di amministrazione, e sembra essere completamente idoneo…

[Jacob_Peebles]

Ok, in mancanza di altre idee, abbiamo modificato la frequenza dei digest in giornaliera per tutti gli utenti tramite l’amministratore, impostandola a 1440.

E improvvisamente sono stati inviati tutti i digest…

Qualcuno ha idea del perché? La modifica della frequenza non dovrebbe avere alcun impatto, dato che vediamo che questi utenti erano idonei con la frequenza settimanale.

[Jacob_Peebles]

Ho parlato troppo presto, lo spostamento della frequenza ha funzionato per un gruppo di utenti (un sito) ma per un altro non ha sortito alcun effetto. Il mistero continua…

[Moin]

@Jacob_Peebles

Qualcuno ha un’idea del perché sia così? Cambiare la frequenza non dovrebbe avere alcun impatto dato che possiamo vedere che questi utenti erano idonei con la frequenza settimanale.

Penso che possa essere dovuto a uno degli ultimi requisiti nella query che ho collegato sopra.

Dopo aver verificato che l’utente è reale, attivo, non in staging e non sospeso, e aver verificato che non abbiano disabilitato le newsletter e che la frequenza sia maggiore di 0, che ci sia un’email primaria e che il punteggio di rimbalzo sia a posto, ci sono alcuni controlli basati sul tempo:

Ultimo accesso è avvenuto più di digest_after_minutes fa
Ultimo accesso è avvenuto entro suppress_digest_email_after_days
L’ultimo controllo se l’utente dovrebbe ricevere una newsletter è avvenuto digest_after_minutes fa.

Penso che quest’ultimo possa essere la causa. Se Discourse ha tentato di inviare la newsletter ieri e digest_after_minutes è una settimana, allora non ci proverà di nuovo fino a quando non sarà passata una settimana. Se lo riduci, il prossimo tentativo avviene prima.

[tobiaseigen]

@Jacob_Peebles sembra che tu stia lottando con questo da un po’! Penso che Digest Emails Not Sending to All Users – Need Help Debugging a marzo riguardi lo stesso problema, ho ragione?

L’ultimo post di Moin ti ha aiutato? Se sì, faccelo sapere in modo che possiamo chiudere questo argomento.