这解决了 post_actions 的问题，感谢你的建议！
我们目前主要还看到两个失败：
GET https://devforum.roblox.com/notifications 对于拥有带有 bigInt ID 的通知的用户返回 404。
新通知未在顶部菜单中显示，但旧通知在导航到个人资料时可见。
Jobs::GrantAnniversaryBadges 计划任务失败。
有没有可能通知的模型/控制器/服务仍然被硬编码为将 notifications.id 字段定义为整数？
非常不可能……404 听起来不对，/logs 中有什么描述这个问题吗？
遗憾的是，我在 /logs 中找不到任何特别有用的信息，但当我本地重现此问题时，我看到请求进来然后是 404，但只有当我将我的最新通知的 ID 设置为 bigint 时才会发生（当它在 int32 范围内时工作正常）
查看后，我注意到当我调用 http://localhost/notifications.json?limit=30 时会收到一个有效响应：
{
"notifications": [
{
"id": 2148935910,
"user_id": 2,
"notification_type": 5,
"read": true,
"high_priority": false,
"created_at": "2023-02-16T00:50:53.135Z",
"post_number": 2,
"topic_id": 8,
"fancy_title": "Welcome to the Lounge",
"slug": "welcome-to-the-lounge",
"data": {
"topic_title": "Welcome to the Lounge",
"original_post_id": 13,
"original_post_type": 1,
"original_username": "blarouche",
"revision_number": null,
"display_username": "blarouche"
}
}
],
"total_rows_notifications": 1,
"seen_notification_id": 1001,
"load_more_notifications": "/notifications?offset=60&username=bjlarouche"
}
但是，一旦我传递 recent 查询参数，即 http://localhost/notifications.json?recent=true&limit=30，这就是通知菜单调用的内容？
{
"errors": [
"The requested URL or resource could not be found."
],
"error_type": "not_found"
}
编辑：我们认为这是因为 current_user.seen_notification_id 仍然是整数 
我认为我们现在安全了！
我们注意到，除了 notifications.id 本身之外，还需要迁移其他引用 notification_id 的表中的列。否则，services/notifications.rb 或 services/badge_granter.rb 将会抛出错误。
对于将来遇到此问题的任何其他大型论坛设置，我们是这样做的……
总共，我们需要迁移四个表中的四列：
notifications.iduser.seen_notification_iduser_badges.notification_idshelved_notifications.notification_id我们最初使用上面建议的 ALTER 命令来处理 #1，但后来如上所述，我们选择使用 ActiveRecord 迁移，这样迁移文件就会累加到 schema 中。
# frozen_string_literal: true
class ChangeNotificationsIdToBigint < ActiveRecord::Migration[6.1]
def change
change_column :notifications, :id, :bigint
end
end
# frozen_string_literal: true
class ChangeUserSeenNotificationIdToBigint < ActiveRecord::Migration[6.1]
def change
change_column :users, :seen_notification_id, :bigint
end
end
# frozen_string_literal: true
class ChangeUserBadgesNotificationIdToBigint < ActiveRecord::Migration[6.1]
def change
change_column :user_badges, :notification_id, :bigint
end
end
# frozen_string_literal: true
class ChangeShelvedNotificationsNotificationIdToBigint < ActiveRecord::Migration[6.1]
def change
change_column :shelved_notifications, :notification_id, :bigint
end
end
我们在设置中有一个自定义的 Dockerfile（我们构建镜像，以便在 Kubernetes 上的不同资源上运行 discourse 和 sidekiq），因此将这些文件作为 Dockerfile 的一部分复制到 /db/migrate 中非常简单。
然后，我们只需让 rake db:migrate 处理其余的事情。一旦我们对所有 discourse 和 sidekiq pod 进行了滚动重启，一切都按预期运行了 
。
很棒的数据，我们将在核心 Discourse 中迁移它到 bigint。这是一个昂贵的举动，但这肯定会在大型论坛上再次出现，所以我们最好现在就修复它。
注意… OP 是关于 post_id… 溢出它将比 notifications 难得多。21 亿帖子肯定会发生，但 biginting post_id 的成本远高于 notification id。我们可以稍等一下处理那个定时炸弹。
布兰登，
我认为我们可能会采用：
这里的权衡之处在于，我不想因为一两个论坛达到了惊人的 25 亿条通知的壮举而“惩罚” 40,000 个 Discourse 实例。
你怎么看？
（注意：它还会捕获你遗漏的一个——还有一个聊天表）
这会很棒，看起来是个聪明的解决方案 
在此处进行总结 - 这现在已合并。 
此主题已在 4 天后自动关闭。不允许回复。