This question already has answers here:
Is there a Rails Console command (Rails 3+) to reload changed code?
(3 answers)
Closed 7 years ago.
I was using the Rails Console to test a few things by hand and found that one of my initializers (under config/initializers) had an error. I exited the console, made the change, and ran "rails c" again. Much to my surprise, the updated initializer was not executed.
Here is what I found:
-- If I start a new Bash session and enter "rails c" all the initializers get executed.
-- If I add / change an initializer and then re-run "rails c" within the same Bash session, the initializers are not executed.
This occurs under development which disables caching.
What the heck is going on? Thanks.
The introduction of Spring was meant to make loading your rails app faster, by keeping a copy of the app in memory and only reloading what changes.
Unfortunately, sometimes your initializers can stay exactly the same, but they need to be re-run. An example is the "business_time" gem, which generates an initializer that loads a YAML file. You can change the YAML file and restart console, but Spring sees that your initializer hasn't changed, so it doesn't re-run it. Thus, the changes to your YAML file go unnoticed, This is a very difficult error to troubleshoot.
If you're having initializer problems, then exit out of console and run:
bundle exec spring stop
before going back into console. This will force a fresh reload of the initializers.
You can also disable Spring entirely by removing the gem from your Gemfile.
Type this command into rails
reload!
It's reload your rails c
Related
I have a Rails app running version 6.1.1 and currently, we use Ruby 2.7.2
While trying to upgrade to Ruby 3, I'm facing an interesting issue: some code apparently is blocking the main thread. When I try to boot the server or run the tests, the console stuck and I can't even stop the process, I have to kill it.
I tracked it down to one gem called valvat, used to validate EU VAT numbers. I opened an issue on its Github repo but the maintainer couldn't reproduce even using the same Gemfile.lock I have, which lead me to believe that it might not be just the gem, gotta be something else in my code.
This is what happens when I try to boot the server:
=> Booting Puma
=> Rails 6.1.1 application starting in development
=> Run `bin/rails server --help` for more startup options
^C^C^C
as one can see, I can't even stop it, the thread is now hanging and I can't tell exactly by whom.
I tried to run the specs with -b -w to see what I can see but got the same error: the thread hangs and the warnings I get from Ruby are just generic ones like method already defined or something like that.
This is the last output from the console while running specs with -b -w before the thread hangs:
/Users/luiz/rails_dev/app/config/initializers/logging_rails.rb:18: warning: method redefined; discarding old tag_logger
/Users/luiz/.rbenv/versions/3.0.0/lib/ruby/gems/3.0.0/gems/activejob-6.1.1/lib/active_job/logging.rb:19: warning: previous definition of tag_logger was here
thing is, I also get these warnings when I remove the gem and run this command though the specs run without issues then.
Is there a way to track this down to whatever is causing the thread to hang?
If you have no error message, it's hard to understand where exactly your application hangs.
As the developer cannot reproduce with your Gemfile.lock, it's possible that one of your config file or initializers is the culprit. You could create a new blank application with the same Gemfile, add your config and initializers files one by one, and test each time if the server runs until you find which one is causing the freeze.
Test also your application with another Ruby version (are you using rbenv or RVM?)
Also check your syslog, as valvat calls a web service you may find connection errors there. Check this doc on how to access your syslog: https://www.howtogeek.com/356942/how-to-view-the-system-log-on-a-mac/
I inherited a Rails application and am having quite a difficult time generating a model. Running 'rails generate model Account' pauses for a moment, but then returns me to the command prompt without the output I would normally expect from a successful operation.
Environment info:
-Rails 4.2.5
-Ruby 2.3.0p, loaded via RVM
I've spent hours trying to debug this myself and have found a few interesting things:
1.) Generating a controller works as expected, only models seem broken
2.) If I create a new Rails project I can generate models as expected
3.) I've verified that spring is not running, using "spring stop"
4.) A similar problem is mentioned in this thread by a user with my same environment. I verified I'm in the proper dir, and also tried running "bundle update" as suggested by a user, but that didn't resolve the problem.
A few other resources allude to this being a problem with RVM, but rolling back to older versions of Ruby haven't made a difference.
Any idea what I'm doing wrong here?
Try the following commands:
bundle config --delete bin
rake rails:update:bin
Was able to reach out to one of the previous developers and learned that I'm dealing with JSONClient models and that's why it isn't working for me. D'oh!
I'm receiving an error from a gem file:
~/.rvm/gems/ruby-2.1.2/gems/psd-2.1.2/lib/psd/layer_info/typetool.rb:127:in `to_css': (error is not important)
I want to debug the gem, so I went to that file and added a debugger. It doesn't works. Next I added a raise, just to test. Doesn't works. I went to lunch, and 20 minutes after the debugger line was working. I removed it, run the process again and the debugger was still pausing the script execution, even when the line was not longer on the file.
I run my script with
rails runner myscript.rb
Why is this happening? Is there some kind of cache/opcode that avoids to read the gems source file? I'm not running a webserver, and there is no instance of the application running.
A few things might help you.
How are you opening the code? bundle open? Or are just manually opening the files in the rvm directories? Using bundle open <gem name> will be easiest.
Is spring running? When you modify the gems in your bundle, you will need to issue the command spring stop from the root of your code. This will allow the changes to actually be used.
I bet that spring is causing your issues. If it is, you will need to run spring stop each time that it automatically starts and you'd like to change the code.
I'm trying to create a migration for my app, and in this app I'm using a gem that tries to startup a different service upon app startup. Apparently, creating a migration...
rails generate migration AddSomeStuffToTable stuff:string
...activates the app, and this gem which tries to connect to startup the service. It appears that starting up the app via generating a migration makes the service startup unable to connect, so it just keeps sleeping and trying again, never actually running the migration.
In this gem, I've already dealt with this for rake, so this is what I've got so far:
MyService.start unless defined? Rake or defined? IRB
This handles the rake problem (like rake db:migrate, rake db:populate), but how can I handle the creation of migration, which (as far as I know) is not a Rake task?
You could try using environment variables for disabling the service:
MyService.start unless ENV['NO_SERVICE']
And run your command like this:
NO_SERVICE=1 rails generate migration AddSomeStuffToTable stuff:string
However, I doubt this scales well, especially if multiple developers are in the app. A better approach might be to do the reverse of this, to only start the service if a particular env variable is present. However, going this direction, you'd need to make sure your app servers set this variable, for example:
Apache: SetEnv START_SERVICE 1
nginx: env START_SERVICE=1
thin: START_SERVICE=1 thin start
I have a Rails app installed on a Slicehost server running Apache 2 and Ubuntu LTC 10.04. Things have worked beautifully up until now: I edit a file, do a quick mongrel_rails cluster::restart, and the changes are reflected in production. However, suddenly this process has broken down.
For example, I have a class called Master located in /lib/master.rb. I added a new method to this class that simply runs puts "it works!", then restarted the mongrel cluster. Looking at the production logs, the server throws an error and thinks this method doesn't exist. When I go to the console using ruby script/console production, however, I can use this new method perfectly. I even tried deleting the file containing entire Master class. Once again, the production thought it was still there, but the production console correctly recognized it was missing.
Any ideas? How can the production environment detect a class that doesn't even exist anymore?
Funny, I spend 2 hours debugging this, then post to StackOverflow and figure it out in 20 minutes.
The problem is that I needed to also restart my background jobs as well. They were running the old version of the classes stored in /lib. It's interesting that this problem has never snagged me before.