Le conseil de Rubocop est bon, mais je ne pense pas que ce soit la cause de cette erreur. (le « risque » qu’il mentionne fait référence aux verrous sur les tables à fort trafic qui affecteraient le trafic de production. Ce n’est donc pas quelque chose qui causerait des erreurs dans un environnement de test)
Vous pouvez probablement reproduire la même erreur localement en faisant RAILS_ENV=test bin/rake db:drop db:create db:migrate (c’est-à-dire en migrant une base de données totalement à partir de zéro, avec le plugin locations activé)
Je soupçonne que le problème est que vous invoquez des tâches Rake dans une migration. Dans le cœur, nous évitons généralement d’exécuter tout type de code d’application dans les migrations en raison des effets secondaires étranges qui peuvent se produire. Il est préférable de s’en tenir au SQL brut.
Dans ce cas, mon hypothèse est que le cache de schéma ActiveRecord est rempli tôt dans les migrations (lorsque topics.off_topic_count existe toujours). Ensuite, lorsque votre tâche Rake s’exécute, elle s’exécute avec un ancien cache de schéma et ActiveRecord essaie donc de charger des colonnes qui n’existent plus.
Vous pouvez probablement atténuer le problème en ajoutant ActiveRecord::Base.clear_cache! avant d’invoquer les tâches Rake… mais ne le prenez pas comme une recommandation 
. La meilleure chose à faire serait d’éviter d’invoquer les tâches Rake complètement. Si vous avez besoin de manipuler quelque chose dans la base de données, utilisez du SQL brut dans la migration.