Bootstrap 错误：关系 "ai_agent_mcp_servers" 不存在

支持 安装
1

Bootstrap 启动失败，报错如下：

PG::UndefinedTable: 错误：关系 "ai_agent_mcp_servers" 不存在
2

所以，这里有一份来自 ask.discourse.com 的 bug 报告，但首先，我想分享它提供的一段内容：

我决定让它保持原样，不“直白简短”。:rofl:（我并没有笑倒在地，但我确实真的笑出了声。）

这看起来是一份可信的报告，而且可能比我写的更好。

来自 ask 的 bug 报告

以下是你可以发布到 Meta 的简洁 bug 报告：

更新后，在 `db:migrate` 期间 bootstrap 失败，报错：

```text
PG::UndefinedTable: ERROR:  relation "ai_agent_mcp_servers" does not exist

失败的迁移文件是：

/plugins/discourse-ai/db/migrate/20260319070000_add_selected_tool_names_to_ai_agent_mcp_servers.rb

看起来该迁移试图在 ai_agent_mcp_servers 表尚未存在时就为其添加列。

日志中的相关部分：

== 20260319070000 AddSelectedToolNamesToAiAgentMcpServers: migrating ==========
PG::UndefinedTable: ERROR:  relation "ai_agent_mcp_servers" does not exist
...
/var/www/discourse/plugins/discourse-ai/db/migrate/20260319070000_add_selected_tool_names_to_ai_agent_mcp_servers.rb:5

这看起来是 discourse-ai 中的迁移顺序问题，或者是缺少一个本应创建 ai_agent_mcp_servers 表的早期迁移。

环境信息：

  • 官方 Docker 安装
  • 在 bundle exec rake db:migrate 时 bootstrap 失败
  • 日志中显示的插件包括 discourse-citationwizard 和 discourse-prometheus

完整报告 / 日志：
Bootstrap 错误：relation “ai_agent_mcp_servers” 不存在

3

我必须知道听起来会怎样。……

当然——这是一个更符合 pfaffman 风格的版本：

这看起来像是 `discourse-ai` 迁移过程中的一个 bug。

Bootstrap 在以下位置失败：

```text
/plugins/discourse-ai/db/migrate/20260319070000_add_selected_tool_names_to_ai_agent_mcp_servers.rb

错误信息为：

PG::UndefinedTable: ERROR:  relation "ai_agent_mcp_servers" does not exist

因此，该迁移尝试修改一个尚未创建的表。

相关日志：

== 20260319070000 AddSelectedToolNamesToAiAgentMcpServers: migrating ==========
PG::UndefinedTable: ERROR:  relation "ai_agent_mcp_servers" does not exist
...
/var/www/discourse/plugins/discourse-ai/db/migrate/20260319070000_add_selected_tool_names_to_ai_agent_mcp_servers.rb:5

看起来可能是以下情况之一：

  • 迁移顺序错误，或者
  • 创建 ai_agent_mcp_servers 表的迁移缺失或未被识别。

原始报告及完整日志：
Bootstrap 错误：relation “ai_agent_mcp_servers” 不存在


如果你愿意，我还可以将其改得更加简洁/带刺。
4

这些看起来顺序正确……

你在日志中看到任何证据表明第一个迁移已运行吗？

（顺便一提，我更喜欢你在主贴中最初的人工撰写报告。它只陈述事实，没有得出可能不正确的结论。）

1 个赞
5

啊哈，情况是这样的。看来问题出在我们俩都用了 AI，而它既愚蠢又懒惰。另一种解释是运气不好，但看起来 Claude（我用的那个）拿不到时间戳（这可真不酷，Claude），只能拿到日期戳，然后加一个计数器，所以我们俩都在同一天工作。

以下是最近几次运行的迁移：

   up     20260316000001  Create discourse citationwizard openalex api keys
   up     20260316000002  Create discourse citationwizard api key daily snapshots
   up     20260316071735  Rename automation api key scope resource
   up     20260316071736  Rename ai api key scope resource
   up     20260316071737  Rename data explorer api key scope resource
   up     20260319000000  ********** NO FILE **********
   up     20260319000001  Create discourse citationwizard user lookup events
   up     20260319000002  Create discourse citationwizard citation wizard sessions
   up     20260319033623  ********** NO FILE **********
   up     20260319055039  ********** NO FILE **********

而 discourse-citationwizard（它支持 https://www.citationwizard.net/，一个面向学术界的引用/参考文献工具）也在同一天进行了迁移。我当时觉得那次迁移有点可疑，但没想到会产生这样的影响……

这就是为什么 plugins/discourse-ai/db/migrate/20260319000001_create_ai_agent_mcp_servers.rb 无法运行的原因。

而我运气不好，我的迁移先执行了（改我的代码比改你的更容易）。我现在正试着看看能不能在迁移表中重命名我的迁移……

6

:facepalm:

我们在 AI-AGENTS.md 中确实有这条说明：

但我想它忽略了这条说明 :person_shrugging:

@sam，你在进行这些 discourse-ai 迁移时是否使用了特定的技能或提示？如果我们能尝试使用真实的时间戳，而不是那些可疑的以 0000 结尾的特定数字，将有助于避免冲突 :thinking:

1 个赞
7

我从你的仓库中运行了这段代码，以利用你对 AI 的深厚知识。现在我得到了证实：即使是一组专家，也无法做得比我更好！

所以，是的，Claude，为什么不使用 generate migration 呢？！?!?!

我像这样在数据库中修改了迁移版本号：

UPDATE schema_migrations 
SET version   = '20260319001231' 
WHERE version = '20260319000001';

并将我插件中的迁移文件重命名以保持一致。问题解决了！

我本可以怪自己没能像应该的那样频繁地从 discourse 主分支拉取代码，但毕竟是在同一天发生的，所以即使我每天拉取，恐怕也无济于事。我想我应该在推送之前再从主分支拉取一次并运行迁移，也许吧。但我不会再让这样的迁移问题发生了。

非常感谢你的帮助。这确实是一个奇怪的边缘情况，如果我们俩不在同一天使用 AI，这种情况根本不会发生。

1 个赞