Erreur de lancement de l'application Rails après des migrations qui ne devraient pas l'affecter

Question

J'essaie de déboguer un problème qui a commencé à venir récemment dans mon application Rails (3.0.9), dans laquelle les cas de l'application doivent être redémarrés (non redéployés) lorsqu'une migration non révolutionnaire est effectuée dans la base de données. Cela ne se produisait pas, et je ne trouve pas la raison pour laquelle il aurait dû commencer récemment.

Mon environnement de production a quelques serveurs, chacun utilisant des instances de licorne fourchues, tous partageant une seule instance MySQL. Chaque instance utilise un pool de connexion de 1. J'ai également un serveur qui est utilisé comme un environnement de stadification final pour tester les données en direct, après avoir testé une base de données de mise en scène.

Dans le passé, nous avons été en mesure d'exécuter des migrations sur la DB de production sans redéployer ni même redémarrer les serveurs de licorne de production tant qu'ils étaient des migrations que l'ancien code n'a jamais eu besoin de voir. Par exemple, l'ajout d'un nouveau champ facultatif à une table existante - le code déployé sur le serveur de mise en scène lui écrirait des données, mais les serveurs existants pourraient l'ignorer avec bonheur et continuer à utiliser la DB de la même manière que celle «est prêt à pousser le nouveau code à la production.

Récemment, cependant, nous avons vu une exception lancée par des serveurs de production après avoir exécuté la migration, mais uniquement lorsqu'il essaie d'insérer une nouvelle ligne dans le tableau modifié. Toutes les autres parties de l'application et toutes les autres tables ne sont pas affectées, mais dès qu'il y a un insert, nous obtenons ceci:

NoMethodError: undefined method `name' for nil:NilClass

[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/to_sql.rb:56:in `visit_Arel_Nodes_InsertStatement'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/to_sql.rb:55:in `map'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/to_sql.rb:55:in `visit_Arel_Nodes_InsertStatement'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/visitor.rb:15:in `send'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/visitor.rb:15:in `visit'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/visitor.rb:5:in `accept'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/to_sql.rb:18:in `accept'
[GEM_ROOT]/bundler/gems/rails-83fb5552b6ab/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:111:in `with_connection'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/to_sql.rb:16:in `accept'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/tree_manager.rb:20:in `to_sql'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/select_manager.rb:217:in `insert'

Le problème disparaît si nous redémarrons ensuite les serveurs de production, même s'ils exécutent toujours l'ancien code. Il semble donc que quelque chose soit corrompu dans la connexion lorsque la table est modifiée, même si l'application, si elle n'avait pas atteint cette erreur, serait bien continue de faire ce qui se faisait avant la migration.

J'ai fait un creusage dans ActiveRecord / Arel, mais le plus que je puisse faire est de théoriser qu'à un moment donné, le modèle mis en cache de ce tableau perd toute connaissance des colonnes qu'il a, mais je ne vois pas pourquoi il ferait cela ou pourquoi cela se produirait tout d'un coup.