Editing i18n causes middleware that references constants to explode

[jpcody]

This issue is present in both 4.1.x and 4.2, but not 3.2.x.

In development, using an autoloaded middleware that references an autoloaded constant, an app will work until a *.yml file is changed. Then it will bomb saying the middleware has been removed from the module tree.

Here is a test repo.

Repro steps:

1. rails s
2. change config/locales/en.yml
3. go to http://localhost:3000

To the best of my knowledge, here's what actually happens:

• Updating the .yml file then reloading the page triggers a clear of all autoloaded constants (via the FileChecker)
• This clears the middleware constant that was autoloaded by virtue of config.middleware.use
• The middleware file, which is used in the request after the reload, held a reference to a model, which mightn't have been defined yet. So the page reload uses const_missing in ActiveSupport::Dependencies to look it up
• At this time, the .yml change + page reload had already triggered a clear of the middleware constant. The const_missing call thinks it's going to need to look up the model in the nesting context of the .yml file, because that's where it was referenced. But that constant has been cleared, so we get "A copy of [middleware] has been removed from the module tree but is still active!" from here.

This problem is solvable by explicitly referencing the top-level model as ::ModelName instead of ModelName in the middleware. But as it was a bug introduced in 4.0 and could be a significant time sink, I thought I'd bring it up.

I'm happy to take a stab at resolving this, but I don't grok ActiveSupport::Dependencies enough to make a good first pass.

[thedarkone]

@jpcody sorry, if this sounds unhelpful, but you can't have auto-reloadable middlewares. This means you can't let Rails auto-load it for you, instead you have to require it:

require_relative '../app/middleware/test_middleware'
config.middleware.use "TestMiddleware"

2 things to note here:

• afterwards changes to app/middleware/test_middleware.rb will not be automatically picked up, you will have to restart the server instead,
• the way you use TestModel from middleware is alright in your "test app", but if you assign TestModel (or its instance) into an i-var on TestMiddleware you will run into trouble.

[jpcody]

@thedarkone No need to apologize!

The issue isn't that the middleware isn't auto-reloading. And I'm not assigning TestModel to an i-var.

It's that referencing an autoloaded constant without using the top-level :: prefix from the middleware means whenever i18n files are updated, Rails loses track of the middleware and blows up looking for the constant in the scope of the middleware.

So by definition, referencing a constant from a middleware and updating i18n files breaks an app in development mode.

Does that make sense, or am I not understanding your point?

[thedarkone]

Have you tried adding require_relative as I suggest above?

[jpcody]

@thedarkone I had not, but now I did, and that does indeed fix the problem (In the same way using ::TestModel does). I apologize for responding with essentially "doesn't work", I misunderstood your comment :/

That said, this breaking condition seems sufficiently common and sufficiently difficult to debug because of indirection (The bit where i18n triggers a constant cleanup and the middleware had eagerly claimed the autoloaded constant for itself) that it should be addressed at a framework level.

Maybe there's a middle ground of just adding a section in the guides that middleware can't be auto-reloaded by Rails? And perhaps the suggestion of adding them to config.autoload_once_paths? Search results suggest putting your middleware in app/middleware/ or lib/middleware and adding lib/middleware to your autoload paths.

[rafaelfranca]

Maybe there's a middle ground of just adding a section in the guides that middleware can't be auto-reloaded by Rails?

👍, if you can please go ahead and submit a PR.