Der Rubocop-Hinweis ist gut, aber ich glaube nicht, dass er die Ursache für diesen Fehler ist. (Das von ihm erwähnte „Risiko“ bezieht sich auf Sperren in Tabellen mit hohem Datenverkehr, die sich auf den Produktionsverkehr auswirken würden. Also nichts, was Fehler in einer Testumgebung verursachen würde)
Sie können wahrscheinlich denselben Fehler lokal reproduzieren, indem Sie RAILS_ENV=test bin/rake db:drop db:create db:migrate ausführen (d. h. eine Datenbank von Grund auf neu migrieren, mit aktiviertem Locations-Plugin)
Ich vermute, das Problem ist, dass Sie Rake-Aufgaben innerhalb einer Migration aufrufen. Im Kern vermeiden wir es generell, jeglichen Anwendungscode in Migrationen auszuführen, da dies seltsame Nebenwirkungen haben kann. Am besten bleiben Sie bei reinem SQL.
In diesem Fall gehe ich davon aus, dass der ActiveRecord-Schema-Cache früh in den Migrationen gefüllt wird (wenn topics.off_topic_count noch existiert). Wenn dann Ihre Rake-Aufgabe ausgeführt wird, läuft sie mit einem alten Schema-Cache und ActiveRecord versucht, Spalten zu laden, die nicht mehr existieren.
Sie können dies wahrscheinlich abmildern, indem Sie ActiveRecord::Base.clear_cache! hinzufügen, bevor Sie die Rake-Aufgaben aufrufen … aber betrachten Sie dies nicht als Empfehlung 
. Am besten wäre es, den Aufruf der Rake-Aufgaben ganz zu vermeiden. Wenn Sie etwas in der Datenbank manipulieren müssen, verwenden Sie reines SQL innerhalb der Migration.