diff options
author | Evan Phoenix <evan@phx.io> | 2013-03-18 19:21:13 -0700 |
---|---|---|
committer | Evan Phoenix <evan@phx.io> | 2013-03-18 19:33:47 -0700 |
commit | 8aadc6f0f4316d96397ef07876b1c0f9ff7dcf6c (patch) | |
tree | 7ce2c747cef424e2f559f2675949c4aa96b6f746 /actionpack/lib/action_view | |
parent | ef5faeb4a5d0d3a49e4ac7dc378459cdba5a76b7 (diff) | |
download | rails-8aadc6f0f4316d96397ef07876b1c0f9ff7dcf6c.tar.gz rails-8aadc6f0f4316d96397ef07876b1c0f9ff7dcf6c.tar.bz2 rails-8aadc6f0f4316d96397ef07876b1c0f9ff7dcf6c.zip |
Change @env_config to @app_env_config
Moral of the story: One must be careful about lazily initializing
instance variables when subclassing.
I would like to draw your attention to https://github.com/rails/rails/issues/4652 where
the reader will see that there appears to be some kind of initialization issue
in rails.
The source of this issue is that:
1) Engine#env_config contains "@env_config ||= ..."
2) Application#env_config contains "@env_config ||= ..."
3) Threads are in the picture
4) Thread A calls Application#env_config, which super's to Engine#env_config
5) After Engine#env_config returns but before Application#env_config sets @env_config again, Thread B begins running
6) Thread B calls Application#env_config
7) Thread B finds @env_config to contain a value (the one set by Engine#env_config) and returns it
8) Thread B blows up because key set by Application#env_config are there.
9) People report bugs with puma, thin, rainbows, webrick, etc
10) Evan becomes tired of seeing these bugs
11) Evan pours himself a stiff drink, puts on Top Gear(tm), and begins debugging
12) Evan finds the source of the bug
13) Evan authors a PR
14) RIGHT NOW.
The bug is fixed by simply using a different ivar name in the methods.
Alternately, Engine#env_config could just return a new Hash each time, not memoizing into @env_config.
I bid you adieu.
Diffstat (limited to 'actionpack/lib/action_view')
0 files changed, 0 insertions, 0 deletions