Совет от Rubocop хорош, но я не думаю, что он является причиной этой ошибки. (Упомянутый им «риск» касается блокировок в таблицах с высокой нагрузкой, что влияет на продакшн-трафик. Это не то, что могло бы вызвать ошибки в тестовой среде.)
Вы, вероятно, сможете воспроизвести ту же ошибку локально, выполнив команду RAILS_ENV=test bin/rake db:drop db:create db:migrate (то есть миграцию базы данных с нуля с включённым плагином locations).
Я подозреваю, что проблема в том, что вы вызываете задачи Rake внутри миграции. В ядре Discourse мы обычно избегаем выполнения любого кода приложения внутри миграций из-за возможных странных побочных эффектов. Лучше использовать сырой SQL.
В данном случае я предполагаю, что кэш схемы ActiveRecord заполняется на раннем этапе миграции (когда topics.off_topic_count ещё существует). Затем, когда запускается ваша задача Rake, она работает со старым кэшем схемы, и поэтому ActiveRecord пытается загрузить столбцы, которые больше не существуют.
Вы, вероятно, сможете смягчить проблему, добавив ActiveRecord::Base.clear_cache! перед вызовом задач Rake… но не воспринимайте это как рекомендацию 
. Лучшее решение — вообще не вызывать задачи Rake. Если вам нужно манипулировать данными в базе данных, используйте сырой SQL внутри миграции.