我们在 Discourse 3.6 版本上遇到一个问题，部分用户本应收到摘要邮件但从未收到。
我们已为受影响的用户确认了以下几点：
enable_digest_emails 为 true
用户已不活跃足够长的时间以触发摘要邮件
邮箱地址有效且已确认
邮件提供商没有退回或抑制邮件
其他邮件（通知等）发送正常
在“管理”->“邮件”->“已发送日志”中没有找到摘要邮件记录
当使用“管理”->“邮件”->“摘要测试”时，系统正确显示“是的，应该发送摘要”——但实际上没有发送或记录任何内容。
Sidekiq 或生产日志中没有出现相关错误。
是否有人在 3.6 版本上遇到过摘要邮件无声失败的情况，即使管理界面中的所有设置和资格检查都表明用户应该收到一封？
您是否已检查用户偏好设置中的电子邮件选项卡？
更新 / 重现步骤 (Discourse 3.6)
我使用 Rails 控制台运行了一个显式的重现步骤，以确认作业层面正在发生什么。以下是我们为受影响用户看到的：
站点：hvac
现在：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
– 用户 –
id：42122
username：milnerlarry
active：true
suspended：false
email_digests：true
digest_after_minutes：10080
eligible_by_time：true
– 最近 15 封电子邮件日志 –
2025-10-01 | type=digest | bounced=false
2025-09-22 | type=digest | bounced=false
perform_deliveries_now：true
然后，当我手动强制构建摘要时，Discourse 认为它正在构建摘要，但返回：
mail = UserNotifications.digest(u)
=> Built digest mail: subject=nil bytes=50
因此，Discourse 认为它正在构建摘要，但实际上是空的（subject=nil）——因此在作业运行时被静默跳过。没有创建 EmailLog 条目，也没有发送任何内容。
这证实了：
使用以下命令内联运行作业：
Jobs::UserEmail.new.execute(“type” => “digest”, “user_id” => u.id”)
产生相同的结果——没有创建新的 EmailLog 行。
可能的原因：
摘要似乎由于“空摘要”条件而被跳过——也许 Discourse 3.6 评估包含内容的方式发生了变化。管理员 → 电子邮件 → 摘要测试视图正确渲染了摘要，但后台作业没有看到要包含的内容。
摘要：
符合条件的用户
活动电子邮件 + 有效的 SMTP
管理员摘要测试正确渲染
后台摘要作业被静默跳过（空摘要）
未记录 EmailLog 或发送尝试
希望团队能确认——Discourse 3.6 中 UserNotifications.digest 收集内容的方式是否存在回归？
我们在这里做了更多的工作，发现（在 4k 用户中）有一小部分用户确实能够可靠地收到活动摘要。
将其中一位收到摘要的用户与另一位未收到摘要的用户进行比较，他们的设置没有任何差异。
===== xxxxx (ID: 4149) =====
活跃：true，暂停：false，静默：false
电子邮件已确认：false
摘要已启用：true
摘要频率：10080 分钟
上次看到：2025-03-24 20:58:55 UTC
上次发送电子邮件：2025-10-16 17:07:53 UTC
已静音类别：
用户统计摘要尝试：2025-10-16 17:07:53 UTC
发送电子邮件总数：16
===== xxxxxxx (ID: 42206) =====
活跃：true，暂停：false，静默：false
电子邮件已确认：false
摘要已启用：true
摘要频率：10080 分钟
上次看到：2025-09-14 15:52:54 UTC
上次发送电子邮件：2025-10-01 23:30:33 UTC
已静音类别：
用户统计摘要尝试：2025-10-16 17:32:34 UTC
发送电子邮件总数：2
当然还有其他设置，但我认为无论如何这都是一个有趣的比较。
有人能提供一个 Rails 命令来检查有多少摘要/活动摘要真正逾期了吗？本质上是一个系统是否按设计发送摘要的运行状况检查。
您可以尝试以下 Rails 控制台查询，这些查询会列出已启用电子邮件摘要且即将收到下一封摘要电子邮件的用户：
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
摘要是否被跳过是因为用户没有访问“Suppress digest email after days”？
@jahan_gagan 这很有用，但它会告诉我们谁将收到摘要/活动摘要，但不会告诉我们谁没有收到活动摘要。这有意义吗？问题是我们如何查看谁没有收到他们应该收到的摘要。
@Moin 我们已将其设置为 0 - 这不应成为一个因素。
您确定 0 会禁用它吗？您尝试过使用较大的数字吗？
@Moin 谢谢，已将其更改为 3000 - 发送的摘要没有变化。仍然看到数百条以每周频率（现在已超过两周）发送但未发送的。
鉴于没有其他想法，我们通过管理员将所有用户的摘要频率时间更改为每日 1440。\n\n然后所有摘要都发送了……\n\n有人知道为什么会这样吗？更改频率应该没有影响，因为我们看到这些用户符合每周频率的条件。
哎呀，我说得太早了，更改频率对一组用户（一个站点）有效，但对另一组用户却无效。谜团仍在继续……
我认为这可能是因为我上面链接的查询中的最后一个要求之一。
在检查用户是否真实、已激活、未暂存且未被暂停，并检查他们没有禁用摘要且频率大于 0，并且有主电子邮件且反弹分数正常之后，还有一些基于时间的检查：
上次看到是在 digest_after_minutes 之前
上次看到是在 suppress_digest_email_after_days 范围内
上次检查用户是否应收到摘要是在 digest_after_minutes 之前。
我认为最后一个可能是原因。如果 Discourse 昨天尝试发送摘要，而 digest_after_minutes 是一周，那么它要到一周后才会再次尝试。如果减少这个值，下一次尝试就会更快发生。
@Jacob_Peebles 看来你为此挣扎了很长时间！我认为早在三月份的 Digest Emails Not Sending to All Users – Need Help Debugging 是关于同一个问题，我说得对吗？
Moin 的最新帖子有帮助吗？如果有帮助，请告诉我们，以便我们结束这个话题。
