Mounted application is not reloaded by Rack::Reloader

[qortex]

Describe the bug
When a modification is made in a mounted application code, changes are not reloaded and rack-app serves the not-modified app.

To Reproduce
Simple rack-app:

require 'rack-app'

puts 'Identity App file loaded'

module Identity
  class IdentityApp < Rack::App
    get '/signup_token' do
      { token: 'Ok token' }.to_json
    end
  end
end

mounted in my main app:

mount Identity::IdentityApp, to: '/v3/identity'

Expected behavior
Now, I change the signup_token response (even doing a syntax error) and the response to a request is not modified until I restart the main rack-app.

The file itself is reloaded by Rack::Reloader since the puts statement shows up in the console.

ruby interpreter
MRI

ruby version
2.7.1

rack-app version
7.6.3

[qortex]

But, if the handler just calls another class that gets reloaded, it's ok. Example:

# in controller/my_controller.rb
module Identity
  class SignupController
    def signup_token
      # changes here are auto-reloaded
    end
  end
end

So I guess that's the mounted object that gets built once and for all and is never reloaded. Which makes sense since the mount call has no reason to be executed again. Am I getting that right? Maybe it's related to #34 ?

[adamluzsi]

Hi @qortex,

Can you explain a bit more about what does it mean "Now, I change the signup_token response"?
Maybe if you could provide a use-case, I would greatly appreciate it. 👍
Does that mean, there is a use-case where you dynamically rewrite your code in runtime,
or this is about local development with some form of hot reload like the rtomayko/shotgun tool?

On a high level, I rarely had use-case where the application source code is interpreted multiple times into the same process runtime, so it's uncharted waters for me. I used the tool mentioned above, shotgun, but that one always makes a new process fork and load the code in the isolated forked process during the HTTP request.

Cheers,
Adam L.

[qortex]

I use vanilla Rack::Reloader to handle hot-reloading. I didn't dig into Shotgun but I understand it serves the same purpose (I saw comments about it not being good for multithreading though, didn't explore).

I think what happens is what I described above, but I guess it's not really worthwhile to spend time fixing it. For it to prove useful, it would mean the logic inside the request handler is complex and often changed. And that would advocate for factoring it out in a controller class -- which works well with reloading as I described above.

I'll close this issue, let me know if you think it should stay open!

[adamluzsi]

I think it's still wort to think about it. Maybe if I change how the application is being built, I could provide some form of option that disables the way how the route is pre-built.
Shotgun is a development tool, should not be used too much with multithreading, unless your application is written in a way that you use ruby threads to provide some form of queue -ing, but I advise against that until ruby3 + process guilds.