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…