E-mails de resumo não são enviados para usuários, mesmo com todas as condições atendidas (Discourse 3.6)

[Jacob_Peebles]

Estamos usando o Discourse 3.6 e estamos vendo um problema em que alguns usuários que deveriam receber e-mails de resumo nunca os recebem.

Aqui está o que confirmamos para o usuário afetado:

• enable_digest_emails é verdadeiro

• O usuário ficou inativo por tempo suficiente para acionar um resumo

• O e-mail é válido e confirmado

• Sem rejeição ou supressão do provedor de e-mail

• Outros e-mails (notificações, etc.) são enviados corretamente

• Nenhum e-mail de resumo aparece no log do Administrador → E-mails → Enviados

• Ao usar Administrador → E-mails → Teste de Resumo, o sistema mostra corretamente “Sim, um resumo deve ser enviado” — mas nada é realmente enviado ou registrado.

Nenhum erro relacionado aparece nos logs do Sidekiq ou de produção.

Mais alguém viu e-mails de resumo falharem silenciosamente na versão 3.6, mesmo quando todas as configurações e verificações de elegibilidade na interface de administração indicam que o usuário deveria receber um?

[Lilly (Lillian Louis)]

Você verificou as configurações do usuário na aba de e-mail das preferências dele?

[Jacob_Peebles]

Sim, aqui estão as configurações deles e aqui está a renderização do resumo para eles, dizendo que deve ser enviado.

[Jacob_Peebles]

Atualização / Passos de Reprodutibilidade (Discourse 3.6)

Executei uma repro explícita para isso usando o console Rails para confirmar o que está acontecendo no nível do job. Veja o que vemos para o usuário afetado:

site: hvac

agora: 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

– USUÁRIO –

id: 42122

username: milnerlarry

active: true

suspended: false

email_digests: true

digest_after_minutes: 10080

eligible_by_time: true

– ÚLTIMOS 15 LOGS DE E-MAIL –

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

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

perform_deliveries_now: true

Em seguida, quando forcei a construção do resumo manualmente, o Discourse pensa que está construindo, mas retorna:

mail = UserNotifications.digest(u)

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

Portanto, o Discourse pensa que está construindo o resumo, mas ele está efetivamente vazio (subject=nil) — e, portanto, é silenciosamente ignorado quando o job é executado. Nenhuma entrada EmailLog é criada e nada é enviado.

Isso confirma:

• O job é enfileirado com sucesso

• SMTP e entregas estão habilitados

• O job de resumo sai sem erro porque o serviço de e-mail retorna um resumo em branco

Executar o job inline com:

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

produz o mesmo resultado — nenhuma nova linha EmailLog criada.

Causa Possível:

Parece que o resumo está sendo ignorado devido a uma condição de “resumo vazio” — talvez algo tenha mudado na forma como o Discourse 3.6 avalia o conteúdo para inclusão. A visualização Admin → Emails → Testar Resumo renderiza o resumo corretamente, mas o job em segundo plano não vê nada para incluir.

Resumo:

Usuário elegível

E-mail ativo + SMTP válido

Teste de Resumo do Admin renderiza corretamente

Job de resumo em segundo plano ignora silenciosamente (resumo vazio)

Nenhuma tentativa de EmailLog ou envio registrada

Gostaria de confirmação da equipe — há possivelmente uma regressão em como o UserNotifications.digest coleta conteúdo no 3.6?

[Jacob_Peebles]

Fazendo um pouco mais de trabalho aqui, encontramos um punhado (de 4 mil) usuários que estão realmente recebendo os resumos de atividade de forma confiável.

Comparar um desses usuários que recebe resumos com um que não recebe não mostra nenhuma diferença em suas configurações.

===== xxxxx (ID: 4149) =====
Ativo: true, Suspenso: false, Silenciado: false
Email confirmado: false
Digest habilitado: true
Frequência do digest: 10080 minutos
Última visualização: 2025-03-24 20:58:55 UTC
Último email enviado: 2025-10-16 17:07:53 UTC
Categorias silenciadas:
Tentativa de digest de estatísticas do usuário: 2025-10-16 17:07:53 UTC
Total de emails enviados: 16
===== xxxxxxx (ID: 42206) =====
Ativo: true, Suspenso: false, Silenciado: false
Email confirmado: false
Digest habilitado: true
Frequência do digest: 10080 minutos
Última visualização: 2025-09-14 15:52:54 UTC
Último email enviado: 2025-10-01 23:30:33 UTC
Categorias silenciadas:
Tentativa de digest de estatísticas do usuário: 2025-10-16 17:32:34 UTC
Total de emails enviados: 2

Certamente existem outras configurações, mas pensei que esta fosse uma comparação interessante de qualquer maneira.

[Jacob_Peebles]

Alguém pode fornecer um comando rails que possamos executar para verificar quantos resumos / resumos de atividades estão realmente atrasados? Essencialmente, uma verificação de integridade de que o sistema está de fato enviando os resumos conforme projetado.

[jahan_gagan]

Você pode tentar a consulta abaixo no console do Rails, os usuários ativos que têm e-mails de resumo ativados e estão programados para seu próximo e-mail de resumo

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]

É possível que o resumo seja ignorado porque o usuário não visitou por Suprimir e-mail de resumo após dias?

[Jacob_Peebles]

@jahan_gagan isso é útil, mas isso nos dirá quem receberá um resumo/atividade, mas não quem NÃO recebeu seu resumo de atividade. Isso faz sentido? A questão é como vemos quem NÃO está recebendo o resumo que deveria.

[Jacob_Peebles]

@Moin está configurado para 0 - isso não deve ser um fator.

[Moin]

Tem certeza que 0 desabilita isso? Você já tentou um número grande em vez disso?

app/jobs/scheduled/enqueue_digest_emails.rb

[Jacob_Peebles]

@Moin Obrigado, alterei para 3000 - nenhuma alteração no resumo enviado. Ainda vejo centenas com frequência semanal (agora mais de duas semanas) sem serem enviados.

[Jacob_Peebles]

Ok, aqui está um teste para ver quem é elegível agora:

Vamos forçar um envio agora, e nada é enviado…

Pegando um usuário de exemplo que não está recebendo o resumo, e verificando a interface de administração, e eles parecem estar totalmente elegíveis…

[Jacob_Peebles]

Ok, então, por falta de outras ideias, alteramos a frequência do resumo para diária para todos os usuários via admin, para 1440.

E de repente todos os resumos foram enviados…

Alguém tem alguma ideia do porquê isso aconteceu? A alteração da frequência não deveria ter impacto, visto que podemos ver que esses usuários eram elegíveis com a frequência semanal.

[Jacob_Peebles]

Falei cedo demais, a mudança de frequência funcionou para um grupo de usuários (um site), mas para outro, não fez nada. O mistério continua…

[Moin]

@Jacob_Peebles

Alguém tem alguma ideia do porquê isso acontece? Mudar a frequência não deveria ter impacto, já que podemos ver que esses usuários eram elegíveis com a frequência semanal.

Eu acho que pode ser por causa de um dos últimos requisitos na consulta que linkei acima.

Depois de verificar que o usuário é real, ativado, não está em staging e não está suspenso, e verificar que eles não desativaram os resumos e a frequência é maior que 0, há um e-mail principal e a pontuação de rejeição está ok, há algumas verificações baseadas em tempo:

Última vez visto foi há mais de digest_after_minutes atrás
Última vez visto está dentro de suppress_digest_email_after_days
A última verificação se o usuário deve receber um resumo foi há digest_after_minutes atrás.

Eu acho que o último pode ser a causa. Se o Discourse tentou enviar o resumo ontem e digest_after_minutes é uma semana, então ele não tentará novamente até que uma semana tenha passado. Se você reduzir isso, a próxima tentativa acontece mais cedo.

[tobiaseigen]

@Jacob_Peebles parece que você está lutando com isso há bastante tempo! Acho que Digest Emails Not Sending to All Users – Need Help Debugging em março é sobre o mesmo problema, estou certo?

A última postagem de Moin ajudou? Se sim, nos avise para que possamos encerrar este tópico.