Il consiglio di Rubocop è buono, ma non credo che sia la causa di questo errore. (il ‘rischio’ a cui si riferisce riguarda i lock su tabelle ad alto traffico che influirebbero sul traffico di produzione. Quindi non qualcosa che causerebbe errori in un ambiente di test)
Probabilmente puoi riprodurre lo stesso errore localmente eseguendo RAILS_ENV=test bin/rake db:drop db:create db:migrate (cioè, migrando un database completamente da zero, con il plugin locations abilitato)
Sospetto che il problema sia che stai invocando task Rake all’interno di una migrazione. Nel core generalmente evitiamo di eseguire qualsiasi tipo di codice applicativo nelle migrazioni a causa degli strani effetti collaterali che possono verificarsi. È meglio attenersi a SQL puro.
In questo caso, la mia ipotesi è che la cache dello schema di ActiveRecord venga popolata all’inizio delle migrazioni (quando topics.off_topic_count esiste ancora). Quindi, quando il tuo task Rake viene eseguito, viene eseguito con una vecchia cache dello schema e quindi ActiveRecord tenta di caricare colonne che non esistono più.
Probabilmente puoi mitigare aggiungendo ActiveRecord::Base.clear_cache! prima di invocare i task Rake… ma non prenderlo come una raccomandazione 
. La cosa migliore sarebbe evitare del tutto di invocare i task Rake. Se devi manipolare qualcosa nel database, usa SQL puro all’interno della migrazione.