-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clear the cache at the beginning of middleware (paranoid) #66
Conversation
decef04
to
ce38992
Compare
This PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Hey @stokarenko, Thanks for opening the PR! Do you mind sharing more context on how it could in theory happen in production? My initial assumption is that:
That's why the gem uses these lines in test environment: batch-loader/spec/spec_helper.rb Lines 35 to 37 in 4b7596a
It might be worth mentioning about clearing the state in test environment in the readme :) |
Hey @exAspArk,
The only thing from the top of my head - lets imagine that application uses the batch loader during the boot phase, within initializer or, say, as a result of eager loading of class like class User < AR::Base
ADMIN = self.batch_load_something.admins.first
end This way the batch loader cache can leak to the first controller's action dispatched next to startup. Anyway the question as always about "when to wash the beer glasses - after the party or before the next one?" But we still can wipe the dust before the next action ) |
Thank you for your comment. I like your 🍻 analogy :) Yeah, that's an interesting point. Basically, there are cases when people might combine using "out-of-band" batching with batching during regular request/response lifecycles in the same thread (e.g. single-threaded Sinatra)? I was thinking about potentially removing |
From the paranoid point of view - let it be cleared both before and after the request ) |
This PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
We saw recently that controller is trying to render the objects from yet another tenancy, it's just like showing the account data of random user within
My profile
page - serious thing you know )Fortunately that happened for us in test suite - the cache of batch loader was leaking from the places out from true controller context, such as
:controller
and:view
unit tests. That was not a production issue but still, it's much calmer to see the cache erased before the controller evaluation - just in case, the price of possible leak is high enough )In production env the leak can happen still from initializer for instance.