Wednesday, February 04, 2015
Once upon a time, I came across an odd bug in some Rails code that was kicking my butt for some time. The reason it perplexed me was it was a classic Heizenbug that seemed to come and go. (That, and this was a side project that I couldn't devote much focused time to.)
The bug sometimes manifested itself with this error when running tests -
NoMethodError: undefined method `all' for SocialQueue:Class
where SocialQueue is an ActiveRecord model. If I subsetted the tests being run to just the ones that failed, the bug would go away. And, if I ran other tests before, the error would go away. In other words, the act of trying to observe the bug would change it.
Another variant of the error I found when running the server in development mode was:
undefined method arel_table for QueuedPost:Class. Again, QueuedPost is a model class, and I assume it has that method somewhere in the voodo that is ActiveRecord.
The error showed up when I added an "innocuous" tracing statement. If I replaced the tracing statement with a puts statement, it worked. If I put a return statement as the first statement in the tracing method, the error persisted - i.e., nothing in the body of that tracing method was causing harm.
The tracing method was in a module, in a separate file, and just requiring that module would cause the errors. How could that be? The module in question wasn't methods to be included in a class - it's just a name space to put this tracing method. What's so bad about requiring a module?
What else is in that file? Oh yeah, I have some code in there that opens my model classes to add a method to each class. I put the new methods in that file, away from the rest of the model's definitions, because this tracing facility was experimental, and I didn't want to commit to modifying the model classes just yet.
In the words of Merlin Mann, "turns out" in development and test modes, Rails loads class definitions lazily. When my module that opened model classes was loaded, the model classes hadn't necessarily been loaded. If the model was loaded, it worked. Otherwise, it wasn't opening an existing model class, but rather it was opening a new class. Then, when my code that tried to use the models was run, there was already a definition for the class, so Rails didn't load the model class, and the object I thought was a model, was basically a lump of uselessness with the one method I intended to inject into a model class but none of the model methods. I have since heard of lazy loading causing problems in STI.
The long-term solution for my problem is to move those new, injected methods into the main definitions of the models, now that my experiment is over, and I know I want to keep those methods.
In the interim, I came up with a simple hack that can be used anywhere you want to open a model class from some other file (or, maybe I've convinced you not bother - just edit the model). Right before you open the model class, just mention it. For example:
Mentioning the model causes Rails to load it. Then, when you open it, you're actually opening the real model class.
Perhaps there are better ways to skin this cat, but this works, and in the process, I learned about the existence and dangers lazy loading in Rails.