是的，当删除用户时，我们会将他们从已确认参加的任何活动中移除。可能是那段代码导致了这个问题。
3 个赞
因为错误中涉及的所有主题 ID 都是使用了“活动”功能的主题。
嗯，我相当确定我正在删除的这些特定用户并没有进行 RSVP，不过也有可能这些是唯二启用了 RSVP 功能的主题？
3 个赞
哦哦，明白了。
@fzngagan 这里用的是不安全的 .find( 吗？
topics = Topic.find(topic_ids) if topic_ids
参考我刚才推送到 Follow 插件的 修复（不过这里的解决方案可能需要不同，因为涉及多个 ID——是否应该使用 where？）
3 个赞
我刚更新了，但仍然收到 404 错误。
1 个赞
Bart，请稍等，待 @fzngagan 应用并确认修复。
5 个赞
我已推送了一个修复。希望这能解决问题。请检查并确认。
5 个赞
问题解决啦，谢谢！！
6 个赞
我多次在审核队列中看到这样的帖子，其审核原因为“新用户发帖速度异常快”。
经过进一步检查，我发现这些帖子包含受监控的关键词，但审核队列中并未提及这一点。
由于“新用户发帖速度异常快”的标记有 96% 的情况是错误的，而“受监控关键词”的标记 100% 正确——也就是说，如果帖子因包含受监控关键词而进入审核队列，那么它 100% 是需要关注的帖子——我认为“受监控关键词”的优先级应高于“新用户发帖过快”。
想象以下两种情况：
- 帖子因“新用户发帖速度异常快”进入审核队列。该帖子包含一个隐藏在受监控关键词列表中的隐形垃圾链接。→ 帖子被批准，因为没人注意到隐形链接（例如链接隐藏在“.”之后）。→ 失败！
- 帖子因包含受监控关键词进入审核队列（“受监控关键词”优先级高于“发帖过快”）。该帖子同样包含一个隐藏在受监控关键词列表中的隐形垃圾链接。→ 帖子被拒绝，发垃圾信息的用户因“受监控关键词”被删除。→ 成功！
5 个赞
完全同意，这确实是一个临界漏洞。我们能否将此任务添加到某人的待办列表中，@eviltrout？我看到@Roman 仍然被指派了，或许可以交给他？
4 个赞
关于 2.6.0.beta2 版本。提个醒，我发现有些已排队的主题似乎已被删除。我认为发生这种情况的流程大致如下：
- 由于用户输入过快，其帖子被放入审核队列。
- 他们删除了自己的主题（如果这是可能的），可能是为了重新提交。
我不确定这是否符合预期。在审核队列中，标题显示为空白，但帖子正文依然存在，且该用户已被禁言。在用户的公开资料中无法看到任何主题或帖子。
与上述内容无关。 我对筛选选项有个建议。我认为一个非常棒的功能是提供更细粒度的帖子/主题类型筛选。目前“类型”选项包括：
“标记的帖子”和“排队的帖子”同时包含主题和回复。我认为将其改为以下内容会非常实用：
审核类型：
- 已标记
- 已排队
或许还可以考虑将“已标记”进一步细分为“用户标记”和“系统标记”。
此外，再增加一个用于内容类型的筛选器：
内容类型：
- 主题
- 帖子
- 用户
我认为这会非常有用。例如，可以更快地优先处理主题审核，而非帖子/回复审核。目前的筛选器除了“按主题分组”外，几乎没有其他方式可以区分主题和帖子。
另一个建议是调整审核队列的界面，使主题和帖子更容易区分。目前这些信息仅以一些小的灰色文本显示（例如：排队的帖子、排队的主题、标记的帖子、标记的主题）。该文本大小与帖子/主题的分类和标签大小相同。
对我来说，很难立即判断某项内容是主题还是帖子/回复，我经常将两者混淆。
一些想法：
- 调整帖子项中的“主题标题”部分，添加一个 回复图标，使其比主题项更小，并可能包含“回复：”文本；
- 增大项目类型（主题/帖子）的文本大小或强调程度。
2 个赞
尝试批准主题和帖子时，我遇到了 500 错误。当前使用的是 2.6.0.beta3 版本。以下是日志：
ActiveRecord::RangeError (PG::NumericValueOutOfRange: ERROR: integer out of range
)
app/models/reviewable_queued_post.rb:97:in `perform_approve_post'
app/models/reviewable.rb:355:in `public_send'
app/models/reviewable.rb:355:in `block in perform'
app/models/reviewable.rb:353:in `perform'
app/controllers/reviewables_controller.rb:192:in `perform'
app/controllers/application_controller.rb:347:in `block in with_resolved_locale'
app/controllers/application_controller.rb:347:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:336:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:22:in `call'
lib/middleware/request_tracker.rb:176:in `call'
一些可能相关的信息是，我过去曾安装过 Akismet 并已将其卸载（也执行了 rake 任务），详情参见：Feedback on the new Review Queue (2019) - #210 by markersocial
这些项目来自过去 60 天内（auto_handle_queued_age: 60）。我尝试过处理旧帖子（约 2 个月）和最近（过去 3 小时内）的帖子。
我可以批准用户（类型：User），并且“删除用户”选项在排队中的主题/帖子上也能正常工作。
2 个赞
@Roman 这个情况非常奇怪——我们怎么会得到一个这么大的整数？
6 个赞
在尝试创建通知时抛出了错误：
我怀疑我们可能正在以某种方式存储数据。
也许我们使用 int 类型存储了一些 ID？Rails 从 5.1 版本开始对主键使用 BIGINT(8)。
@markersorcial 您能否与我们分享这些查询的结果？
Notification.count
User.count
Topic.count
4 个赞
感谢您对此事的关注 
好的，这是查询结果：
Notification.count: 1506604
User.count: 238083
Topic.count: 936067
3 个赞
更新：我在 Sidekiq 中发现大量任务失败，错误信息与此类似：
Jobs::HandledExceptionWrapper: 封装的 ActiveRecord::RangeError: PG::NumericValueOutOfRange: 错误：整数超出范围
涉及的任务类型（截至目前我注意到的）：
Jobs::PostAlert（最常见）
Jobs::ProcessPost
Jobs::NotifyCategoryChange
1 个赞
这些数字都不应该超过最大限制。我想知道是否有其他内容覆盖了整数值 @Roman。
3 个赞
那一定是别的问题。肯定有什么情况在发生，而且并非特定于审核队列。
这些作业会创建通知，但它们也失败了：
另外，如果我尝试执行类似这样的操作：
Notification.create!(
notification_type: Notification.types[:post_approved],
user_id: 1,
data: {},
topic_id: 1,
post_number: 1311344111111
)
我会得到另一个错误：
ActiveModel::RangeError: 1311344111111 超出了 ActiveModel::Type::Integer 4 字节的限制范围
执行以下操作时也会得到相同的错误：
DB.exec <<~SQL
INSERT INTO notifications(user_id, topic_id, post_number)
VALUES (1, 1, 1311344111111)
SQL
PG::NumericValueOutOfRange: ERROR: integer out of range
6 个赞
@markersocial 我想知道 PostgreSQL 日志是否能帮助我们获取更多关于该错误的信息。您能帮忙检查一下吗？
如果您不知道在哪里可以找到日志，请参阅：
5 个赞
我们的版主非常欣赏能够在彼此之间轻松讨论“标记帖子”，并且相关历史记录会保留在审核队列中。是否可以为“待审帖子”添加同样的功能？我们使用 approve_post_count 设置，要求新用户的前 5 篇帖子必须经过审核。这前 5 篇帖子会成为“待审帖子”，但如果需要版主讨论，他们就必须发起私信，这将脱离审核队列，导致历史记录丢失。
3 个赞