4 ms·
Or a lambda that didn't initialize, say, the customer ID and got it from the last run because of some edge-case in calling it. Ask me how I know this, um, exac
by creeble 7y ago
Or a lambda that didn't initialize, say, the customer ID and got it from the last run because of some edge-case in calling it.
Ask me how I know this, um, exact case.
- yebyen 7y agoYeah, you can get that, "um, exact case" too, with Rails in 2018, ask how I know it's easy to trip over while switching between web servers like Puma and Unicorn, because of the different way they each handle objects threading/forking. I found out when my new Rails 5.1 app which was using Puma, had to be switched to Unicorn so that it could work with our uniform platform for Rails apps. Puma threads are I guess pretty cheap and so are basically disposable, so they are created freshly all the time, but Unicorn process forks are made once per app-start because they're process forks, and incur some greater expenses. So suddenly we noticed when switching to Unicorn that Class vars (those starting with an "@@" which are declared and have values in the class scope) are not reliably empty at the start of a request anymore, but usually had some value left hanging around from the previous request. Class vars are basically global variables so shame on us, now we know. That previous request of course could have come from any logged-in user, so be careful what you store there! It's much easier to say "if the variable is empty, then initialize it thusly" and count on hitting that corner case once in a while, than it is to say "what is the order of my actual dependencies and how do I keep them ordered" – at least it seems easier until it bites you like this!