Skip to content

A Funny Thing Happened While Debugging Code Today

When testing new code, we often use names of baseball players, football players, etc in order to make it a point that the information we are entering is bogus data. It also gives us an easy way to differentiate test cases and say something like “Pujols can’t change his email address.” Until yesterday, this had never been an issue for me.
So I get the phone call that “The last three mornings I have had to the clear the cache for [big name star].” No big deal, I think. We’ve been having an issue with cached transactions ever since we upgraded this application a few months ago. Out of 40,000+ people, it only affects about 9 per month. I thought this was just reporting a new twist on the problem.
I logged into the database to start troubleshooting, found the header record, found the child record causing the problem and was finally able to figure out what has been plaguing us for the past 2 months. If it was the first time a user accessed the system, the flawed child record was not written. However, if a cached header record existed previously, it was purged and a new header and new flawed child record was created. So I put in a patch that would check if cache was pre-existing, check to see if the child record was flawed (the flaw was created by a closed system I have no access to, so I had to work around it), and write things out accordingly.
After putting the patch in, I checked the header for my test user. Wait – this isn’t the [big name star] test user I created. [Big name star] was actually a customer — and he actually was having a problem (or at least his financial manager was). What are the odds on that?

Comments are closed.

  • Recent Tweets…