选择解雇的意外行为

支持
1

5 月新增了一个功能 https://meta.discourse.org/t/selective-dismissal-of-new-and-unread-topics/191641/1。我们最近刚升级到最新版的 Discourse，通过查看代码和数据库日志，我们发现当用户执行“忽略新主题”操作但未进行选择（即仅批量忽略）时，我们在请求参数中向 reset-new 传递了 tracked = false，而没有传递其他内容。

image

检查该 PR 的变更，我认为当我们尝试确定 topic_scope 时，会进入这里 FEATURE: Allow selective dismissal of new and unread topics (#12976) · discourse/discourse@7a79bd7 · GitHub

由于我们没有传递任何 topic_ids，因此跳过了 if 语句，直接跳转到第 989 行。

我们运营着一个规模相当大的 Discourse 服务器，我认为默认包含所有主题的做法开销很大，因为该查询实际上生成了如下 SQL：

LEFT JOIN topic_users ON topic_users.topic_id = topics.id AND topic_users.user_id = xxx WHERE "topics"."deleted_at" IS NULL AND "topics"."id" IN (1, ... 1000000) AND (topics.created_at >= 'date') AND (topic_users.last_read_post_number IS NULL) AND (topics.archetype <> 'private_message') ORDER BY topics.created_at DESC LIMIT 500

据我所知，IN 子句中几乎包含了所有 100 万 + 的主题。

我们能否将批量选择的默认行为改为仅传递具体的 topic_ids，而不是默认包含所有可能的主题？

2

@martin 嘿，抱歉打扰了，看来您推送了上面链接的相关提交。

您能否检查一下这是否是我们所遇到问题的根本原因？在“全部忽略”的默认情况下，我们发现查询中出现了巨大的过滤器列表（约一百万个主题 ID）。（我们的论坛托管了大量的 Discourse 主题）

如果 Discourse 团队目前没有优先级处理此事，我们可以协助提交 PR 来解决这个问题。但我怀疑受此影响的不仅仅是我们，这也可能影响到贵方部分客户的数据库性能。

3

感谢 @forkythetoy 和 @Hooksmith 提醒我此事，我确认这确实是一个巨大的查询问题，即使是在 meta 上也是如此。我今天会为此编写一个修复方案，应该很简单，只需针对用户“新”列表中显示的帖子使用其帖子 ID，而不是使用“所有曾经存在过的帖子”。修复补丁完成后我会在此更新。

5

我今天合并了这个修复：