APP RAILS che lancia un errore dopo le migrazioni che non dovrebbero influire su di esso

Question

Sto cercando di eseguire il debug di un problema che ha iniziato ad arrivare di recente nell'app My Rails (3.0.9), in cui le istanze dell'app devono essere riavviate (non ridistribuite) quando viene eseguita una migrazione non di rottura sul database. Questo non era solito accadere e non riesco a trovare un motivo per cui avrebbe dovuto iniziare di recente.

Il mio ambiente di produzione ha alcuni server, ognuno dei quali utilizza istanze di unicorno biforcuta, tutti condividendo una singola istanza MySQL. Ogni istanza utilizza un pool di connessioni di 1. Ho anche un server utilizzato come ambiente di stadiazione finale per testare contro i dati in diretta, dopo aver testato contro un database di stadiazione.

In passato, siamo stati in grado di eseguire migrazioni sul DB di produzione senza ridistribuire o addirittura riavviare i server di unicorno di produzione fintanto che erano migrazioni che il vecchio codice non aveva mai dovuto vedere. Ad esempio, l'aggiunta di un nuovo campo opzionale a una tabella esistente: il codice distribuito sul server di stadiazione avrebbe scritto dati su di esso, ma i server esistenti potrebbero ignorarlo beatamente e continuare a utilizzare il DB nello stesso modo in cui era stato fino a quando non noi era stato «È pronto a spingere il nuovo codice alla produzione.

Di recente, tuttavia, abbiamo visto un'eccezione lanciata dai server di produzione dopo aver eseguito la migrazione, ma solo quando cerca di inserire una nuova riga nella tabella modificata. Tutte le altre parti dell'app e tutte le altre tabelle non sono interessate, ma non appena c'è un inserto, otteniamo questo:

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'

Il problema scompare se riavviano i server di produzione, anche se stanno ancora eseguendo il vecchio codice. Quindi sembra che qualcosa venga corrotto nella connessione quando la tabella viene modificata, anche se l'app, se non avesse colpito questo errore, andrebbe bene continuando a fare ciò che stava facendo prima della migrazione.

Ho scavato un po 'di ActiveRecord/Arel, ma il massimo che posso fare è teorizzare che ad un certo punto il modello memorizzato nella cache di questa tabella perde qualsiasi conoscenza delle colonne che ha, ma non riesco a capire perché lo farebbe o perché questo Sarebbe accaduto all'improvviso.