Rails 5.1: « firstpos inconnus: NilClass » - l'application d'émission rechargeant

Suite à une mise à niveau des rails 5,0 à 5,1 Je reçois ce moment d'erreur, l'application rechargements, que ce soit des changements de code pendant rails server ou si je l'appelle reload! à partir de la console.

13:53$ rc 
Loading development environment (Rails 5.1.1) 
2.3.1 :001 > reload! 
Reloading... 
ArgumentError: unknown firstpos: NilClass 
    from (irb):1 
2.3.1 :002 >

https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/journey/gtg/builder.rb

Trace d'application est vide, voici la trace Cadre:

actionpack (5.1.1) lib/action_dispatch/journey/gtg/builder.rb:99:in `firstpos' 
actionpack (5.1.1) lib/action_dispatch/journey/gtg/builder.rb:22:in `transition_table' 
actionpack (5.1.1) lib/action_dispatch/journey/routes.rb:58:in `simulator' 
actionpack (5.1.1) lib/action_dispatch/journey/router.rb:92:in `simulator' 
actionpack (5.1.1) lib/action_dispatch/journey/router.rb:28:in `eager_load!' 
actionpack (5.1.1) lib/action_dispatch/routing/route_set.rb:382:in `eager_load!' 
railties (5.1.1) lib/rails/application/routes_reloader.rb:26:in `each' 
railties (5.1.1) lib/rails/application/routes_reloader.rb:26:in `execute' 
railties (5.1.1) lib/rails/application/finisher.rb:141:in `block (2 levels) in <module:Finisher>' 
activesupport (5.1.1) lib/active_support/callbacks.rb:413:in `instance_exec' 
activesupport (5.1.1) lib/active_support/callbacks.rb:413:in `block in make_lambda' 
activesupport (5.1.1) lib/active_support/callbacks.rb:197:in `block (2 levels) in halting' 
activesupport (5.1.1) lib/active_support/callbacks.rb:601:in `block (2 levels) in default_terminator' 
activesupport (5.1.1) lib/active_support/callbacks.rb:600:in `catch' 
activesupport (5.1.1) lib/active_support/callbacks.rb:600:in `block in default_terminator' 
activesupport (5.1.1) lib/active_support/callbacks.rb:198:in `block in halting' 
activesupport (5.1.1) lib/active_support/callbacks.rb:507:in `block in invoke_before' 
activesupport (5.1.1) lib/active_support/callbacks.rb:507:in `each' 
activesupport (5.1.1) lib/active_support/callbacks.rb:507:in `invoke_before' 
activesupport (5.1.1) lib/active_support/callbacks.rb:130:in `run_callbacks' 
activesupport (5.1.1) lib/active_support/execution_wrapper.rb:108:in `run!' 
activesupport (5.1.1) lib/active_support/reloader.rb:113:in `run!' 
activesupport (5.1.1) lib/active_support/execution_wrapper.rb:70:in `block in run!' 
activesupport (5.1.1) lib/active_support/execution_wrapper.rb:67:in `tap' 
activesupport (5.1.1) lib/active_support/execution_wrapper.rb:67:in `run!' 
activesupport (5.1.1) lib/active_support/reloader.rb:59:in `run!' 
actionpack (5.1.1) lib/action_dispatch/middleware/executor.rb:10:in `call' 
actionpack (5.1.1) lib/action_dispatch/middleware/debug_exceptions.rb:59:in `call' 
actionpack (5.1.1) lib/action_dispatch/middleware/show_exceptions.rb:31:in `call' 
railties (5.1.1) lib/rails/rack/logger.rb:36:in `call_app' 
railties (5.1.1) lib/rails/rack/logger.rb:24:in `block in call' 
activesupport (5.1.1) lib/active_support/tagged_logging.rb:69:in `block in tagged' 
activesupport (5.1.1) lib/active_support/tagged_logging.rb:26:in `tagged' 
activesupport (5.1.1) lib/active_support/tagged_logging.rb:69:in `tagged' 
railties (5.1.1) lib/rails/rack/logger.rb:24:in `call' 
sprockets-rails (3.2.0) lib/sprockets/rails/quiet_assets.rb:13:in `call' 
actionpack (5.1.1) lib/action_dispatch/middleware/remote_ip.rb:79:in `call' 
request_store (1.3.2) lib/request_store/middleware.rb:9:in `call' 
actionpack (5.1.1) lib/action_dispatch/middleware/request_id.rb:25:in `call' 
rack (2.0.3) lib/rack/method_override.rb:22:in `call' 
rack (2.0.3) lib/rack/runtime.rb:22:in `call' 
activesupport (5.1.1) lib/active_support/cache/strategy/local_cache_middleware.rb:27:in `call' 
actionpack (5.1.1) lib/action_dispatch/middleware/executor.rb:12:in `call' 
actionpack (5.1.1) lib/action_dispatch/middleware/static.rb:125:in `call' 
rack (2.0.3) lib/rack/sendfile.rb:111:in `call' 
railties (5.1.1) lib/rails/engine.rb:522:in `call' 
puma (3.9.1) lib/puma/configuration.rb:224:in `call' 
puma (3.9.1) lib/puma/server.rb:602:in `handle_request' 
puma (3.9.1) lib/puma/server.rb:435:in `process_client' 
puma (3.9.1) lib/puma/server.rb:299:in `block in run' 
puma (3.9.1) lib/puma/thread_pool.rb:120:in `block in spawn_thread'

Source

2017-06-09 JP Duffy

pouvez-vous essayer ce lien? Https://collectiveidea.com/blog/archives/2016/07/22/solutions-to-potential-upgrade-problems-in-rails-5 – skam

Je viens confronté exactement le même problème. Je sovled en définissant:

config/environnements/development.rb

de:

# Do not eager load code on boot. 
config.eager_load = true

à:

**# Do not eager load code on boot. 
config.eager_load = false

Hope this helps! Cheers, Nic.

Source

2017-06-11 21:18:09 Nic

Je préfère utiliser eager_load sur dev boot comme une sorte d'analyseur de code statique. Si vous avez une erreur de syntaxe * n'importe où * vous le savez immédiatement. Cela dit, je l'ai essayé de toute façon et malheureusement cela n'a eu aucun effet. J'ai également essayé de construire une nouvelle application 5.1.1 rails et les deux façons ont fonctionné comme prévu, avec et sans ressort ... humm –

travaillé pour moi, mais il doit encore y avoir une autre façon de le faire (ou pourquoi serait-il cette option de toute façon à partir de 5.1 on) –

Il semble très indésirable de désactiver une fonctionnalité clé de Rails juste pour contourner ce problème, sans parler d'une fonctionnalité qui peut être nécessaire pour certains. – Todd

Semble qu'il est suspendue de printemps ou quelque chose. Il suffit de lancer spring stop et il devrait s'en aller. Vous pouvez également démarrer la console de rails sans ressort comme suit:

DISABLE_SPRING=true rails c.

Source

2017-07-02 15:09:45

Je ne cours pas le printemps, nous avons rencontré des problèmes avec quand il a été introduit et ne l'a jamais embêté depuis. Pour l'instant je viens de repousser ma mise à jour 5.1. 5.0 fonctionne très bien. –

Ne m'aide pas – Evmorov

Vous n'obtiendrez pas ce bogue dans l'environnement de production et dans un environnement de test (si vous n'utilisez pas Spring). Parce que ce bug "ArgumentError: unknown firstpos: NilClass" vous avez eu "recharger" quand il a essayé de recharger certaines de vos classes.

Dans les environnements de production et de test toutes les choses sont en cache, de sorte que toutes vos choses seront mises en cache et bug ne se produira pas

Malheureusement (pour l'instant) pour l'environnement de développement, j'ai aussi trouvé que cette solution

config.eager_load = false

Source

2017-10-13 13:44:52

Rails 5.1: « firstpos inconnus: NilClass » - l'application d'émission rechargeant

Répondre

Questions connexes