Bootstrap-Fehler: Relation "ai_agent_mcp_servers" existiert nicht

Der Bootstrap-Vorgang schlägt mit diesem Fehler fehl:

PG::UndefinedTable: ERROR:  relation "ai_agent_mcp_servers" existiert nicht

Also, hier kommt ein Fehlerbericht, den ask.discourse.com verfasst hat, aber zuerst möchte ich diesen Abschnitt teilen, den er angeboten hat:

Ich habe mich entschieden, es so zu lassen, wie es ist, und nicht „direkt und kurz". :rofl: (Ich bin nicht auf dem Boden herumgerollt, aber ich habe tatsächlich laut gelacht.)

Dies scheint ein glaubwürdiger Bericht zu sein und wahrscheinlich besser, als ich ihn verfasst hätte.

Fehlerbericht von ask . . .

Hier ist ein prägnanter Fehlerbericht, den du auf Meta posten kannst:

Nach dem Update schlägt der Bootstrap-Vorgang während `db:migrate` fehl mit:

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

Die fehlerhafte Migration ist:

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

Es scheint, dass diese Migration versucht, eine Spalte zu ai_agent_mcp_servers hinzuzufügen, bevor diese Tabelle existiert.

Relevanter Teil des Logs:

== 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

Dies sieht nach einem Problem mit der Migrationsreihenfolge in discourse-ai aus oder nach einer fehlenden früheren Migration, die ai_agent_mcp_servers erstellen sollte.

Umgebung:

  • Offizielle Docker-Installation
  • Bootstrap schlägt bei bundle exec rake db:migrate fehl
  • In den Logs angezeigte Plugins umfassen discourse-citationwizard und discourse-prometheus

Vollständiger Bericht / Logs:
Bootstrap-Fehler: relation „ai_agent_mcp_servers" does not exist

Ich musste wissen, wie ich klingen würde. . . .

Sicher – hier ist eine etwas pfaffman-artigere Version:

Das sieht nach einem `discourse-ai`-Migrationsfehler aus.

Bootstrap scheitert in:

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

mit:

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

Diese Migration versucht also, eine Tabelle zu ändern, die noch nicht erstellt wurde.

Relevante Logausgabe:

== 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

Es scheint entweder, dass:

  • die Reihenfolge der Migrationen falsch ist, oder
  • die Migration, die ai_agent_mcp_servers erstellt, fehlt bzw. nicht erkannt wird.

Ursprünglicher Bericht und vollständige Logs:
Bootstrap error: relation “ai_agent_mcp_servers” does not exist


Falls gewünscht, kann ich es noch knapper/sarkastischer formulieren.

Diese scheinen in der richtigen Reihenfolge zu sein…

Sehen Sie in den Protokollen irgendwelche Hinweise darauf, dass die erste ausgeführt wurde?

(Nebenbei bemerkt: Ich bevorzuge Ihren ursprünglichen, von Menschen verfassten Bericht im OP. Er bleibt bei den Fakten und zieht keine potenziell falschen Schlussfolgerungen.)

2 „Gefällt mir“

Aha. Hier ist, was passiert ist. Es scheint daran zu liegen, dass wir beide KI verwendet haben, und diese ist dumm und faul. Eine alternative Erklärung wäre Pech, aber es sieht so aus, als ob Claude (das habe ich verwendet) keinen Zeitstempel bekommt (NICHT COOL, Claude), sondern nur ein Datumsstempel und dann einen Zähler hinzufügt. Daher haben wir beide am selben Tag gearbeitet.

Hier sind die letzten ausgeführten Migrationen:

   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 **********

Und discourse-citationwizard (das https://www.citationwizard.net/ unterstützt, ein Zitations-/Referenztool für Wissenschaftler) hat am selben Tag eine Migration durchgeführt. Ich fand diese Migration zwar verdächtig, hatte aber keine Ahnung, dass es solche Konsequenzen geben würde. . .

Das ist also der Grund, warum plugins/discourse-ai/db/migrate/20260319000001_create_ai_agent_mcp_servers.rb nicht ausgeführt werden kann.

Und ich hatte das Pech, dass meine Migration zuerst lief (es ist einfacher, meinen Code zu ändern als deinen). Ich versuche jetzt zu prüfen, ob ich meine Migrationen in der Migrationstabelle umbenennen kann. . .

:facepalm:

Wir haben diese Anweisung in AI-AGENTS.md:

Aber ich vermute, sie wird ignoriert :person_shrugging:

@sam, hast du irgendeine spezielle Fähigkeit oder einen speziellen Prompt verwendet, um diese Discourse-AI-Migrationen durchzuführen? Wenn wir versuchen könnten, echte Zeitstempel anstelle von verdächtig spezifischen Zahlen zu verwenden, die auf 0000 enden, würde das wirklich helfen, Kollisionen zu vermeiden :thinking:

1 „Gefällt mir“

Und ich habe das in deinem Repo ausgeführt, um von deinem überlegenen Wissen über KI zu profitieren. Und jetzt bin ich bestätigt: Ein Expertenteam kann nicht besser sein als ich!

Also, ja, Claude, WARUM NICHT GENERATE MIGRATION verwenden?!?!?!

Ich habe die Migrationsversion in der Datenbank wie folgt geändert:

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

Und habe die Migration in meinem Plugin entsprechend umbenannt. Das hat den Haken!

Ich könnte mir selbst die Schuld geben, nicht so oft wie nötig vom discourse-Hauptzweig gezogen zu haben, aber es war derselbe Tag. Selbst wenn ich es täglich getan hätte, hätte es nicht geholfen. Vielleicht sollte ich vor dem Pushen noch einmal vom Hauptzweig ziehen und die Migrations ausführen. Aber so eine Migration wird mir nicht noch einmal passieren.

Vielen Dank für deine Hilfe. Das war definitiv ein seltsamer Randfall, der nie passiert wäre, wenn wir nicht beide am selben Tag KI genutzt hätten.

2 „Gefällt mir“