Le démarrage échoue avec cette erreur :
PG::UndefinedTable: ERREUR: la relation "ai_agent_mcp_servers" n'existe pas
Le démarrage échoue avec cette erreur :
PG::UndefinedTable: ERREUR: la relation "ai_agent_mcp_servers" n'existe pas
Alors, voici un rapport de bug rédigé par ask.discourse.com, mais d’abord, je tiens à partager cet extrait qu’il a proposé :
J’ai décidé de le laisser tel quel, sans le rendre « brutal et concis ».
(Je ne me suis pas roulé par terre, mais j’ai bel et bien éclaté de rire.)
Cela semble être un rapport crédible et probablement meilleur que celui que j’aurais écrit.
Voici un rapport de bug concis que vous pouvez publier sur Meta :
Après la mise à jour, bootstrap échoue lors de `db:migrate` avec :
```text
PG::UndefinedTable: ERROR: relation "ai_agent_mcp_servers" does not exist
La migration qui échoue est :
/plugins/discourse-ai/db/migrate/20260319070000_add_selected_tool_names_to_ai_agent_mcp_servers.rb
Il semble que cette migration tente d’ajouter une colonne à ai_agent_mcp_servers avant que cette table n’existe.
Partie pertinente du journal :
== 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
Cela ressemble à un problème d’ordre des migrations dans discourse-ai, ou à une migration antérieure manquante qui devrait créer ai_agent_mcp_servers.
Environnement :
bundle exec rake db:migratediscourse-citationwizard et discourse-prometheusRapport complet / journaux :
Erreur de bootstrap : la relation « ai_agent_mcp_servers » n’existe pas
Je devais savoir à quoi je ressemblerais. . . .
Bien sûr — voici une version plus style pfaffman :
Cela ressemble à un bug de migration `discourse-ai`.
Bootstrap échoue dans :
```text
/plugins/discourse-ai/db/migrate/20260319070000_add_selected_tool_names_to_ai_agent_mcp_servers.rb
avec :
PG::UndefinedTable: ERROR: relation "ai_agent_mcp_servers" does not exist
Cette migration tente donc de modifier une table qui n’a pas encore été créée.
Log pertinent :
== 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
Il semble que ce soit soit :
ai_agent_mcp_servers est manquante ou n’est pas prise en compte.Rapport original et logs complets :
Erreur de Bootstrap : relation “ai_agent_mcp_servers” n’existe pas
Si vous le souhaitez, je peux aussi le rendre encore plus concis/snarky.
Celles-ci semblent être dans le bon ordre…
Voyez-vous des preuves dans les journaux que la première a été exécutée ?
(A titre d’information, je préfère votre rapport original rédigé par un humain dans le premier message. Il s’en tient aux faits et ne tire pas de conclusions potentiellement incorrectes.)
Aha. Voici ce qui s’est produit. Il semble que cela soit dû au fait que nous avons tous deux utilisé une IA, qui est stupide et paresseuse. Une autre explication serait la malchance, mais il semble que Claude (c’est celui que j’ai utilisé) ne reçoive pas d’horodatage (PAS GÉNIAL, Claude), mais simplement un date stamp suivi d’un compteur. Nous travaillions donc tous deux le même jour.
Voici les dernières migrations exécutées :
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 **********
Et discourse-citationwizard (qui prend en charge https://www.citationwizard.net/, un outil de citation/référence pour les universitaires) a également exécuté une migration le même jour. Je trouvais cette migration suspecte, mais je n’imaginais pas qu’elle aurait de telles implications…
C’est pourquoi plugins/discourse-ai/db/migrate/20260319000001_create_ai_agent_mcp_servers.rb ne peut pas s’exécuter.
J’ai eu la malchance que ma migration s’exécute en premier (il est plus facile de modifier mon code que le vôtre). J’essaie actuellement de voir si je peux renommer mes migrations dans la table de migrations…
![]()
Nous avons cette instruction dans AI-AGENTS.md :
Mais je suppose qu’elle est ignorée ![]()
@sam, as-tu utilisé une compétence ou un prompt spécifique pour effectuer ces migrations de discourse-ai ? Si nous pouvons essayer d’utiliser de vrais horodatages plutôt que des nombres suspects se terminant par 0000, cela aiderait vraiment à éviter les collisions ![]()
Et j’ai exécuté cela depuis votre dépôt pour profiter de votre expertise supérieure en IA. Je suis maintenant vindiqué en sachant qu’une équipe d’experts ne peut pas faire mieux que moi !
Alors, oui, Claude, POURQUOI NE PAS UTILISER GENERATE MIGRATION !?!?!?
J’ai modifié la version de la migration dans la base de données comme ceci :
UPDATE schema_migrations
SET version = '20260319001231'
WHERE version = '20260319000001';
Et j’ai renommé la migration dans mon plugin pour qu’elle corresponde. Cela a fait l’affaire !
Je pourrais me blâmer de ne pas avoir tiré (pull) de la branche principale de Discourse aussi souvent que je le devrais, mais c’était le même jour, donc même si je le faisais tous les jours, cela n’aurait pas aidé. Je suppose que je devrais peut-être tirer de main et exécuter les migrations une fois de plus avant de pousser (push). Mais je ne laisserai plus jamais une migration comme celle-ci se produire.
Merci beaucoup pour votre aide. C’était définitivement un cas limite étrange qui ne se serait jamais produit si nous n’utilisions pas tous les deux l’IA le même jour.