Trucking on With Add-on Bugs

Published in Open Source

For the past week, I have been getting back into the flow of seeking out and fixing potential bugs after my stint at attempting to get my first feature merged in to the Zamboni code base. I experienced some more difficulties with being able to find reproducible bugs but still managed to submit a couple more pull requests to address some interesting problems.

"Can’t Reproduce" Isn’t All Bad

As usual, I started by updating my fork, running schema migrations, updating submodules and forcing a clean database. I found a noteworthy Marketplace bug that seemed to indicate that adding content ratings for an application was not working properly. Mozilla is transitioning all of their apps to require a content rating which is essentially a minimum age requirement (recommended). I was unable to find the spot in my application in order to add a content rating for a test application. I found a page that talked about it but still wasn’t able to find that in my local copy. I asked on IRC and got a quick response from one of the core developers that indicated I had to setup a waffle switch with the following SQL statement:

UPDATE waffle_switch_mkt SET active=1 WHERE name='iarc';

In the Django world, a waffle is a way to turn on and off certain features of an application via flags set in the database. This is great for new features or things that you may want in one environment but not in another. After enabling the waffle, the content ratings menu was presented but I found that I was able to add a new content rating successfully, which directly went against what was stated in the bug description. One thing in the debugging process that becomes difficult is ensuring that my own local environment is an exact replica of the staging and production environment that Mozilla maintains.

With no luck reproducing the content ratings bug, I shifted my focus to an Add-ons bug. It described a situation where by new themes were unable to be edited by those who submitted them. I first figured out how to submit a test theme. One thing that it required was that I create header and footer images that were 3000px by 200px and 3000px by 100px respectively. Adding a new theme also required a category but I found that there were no categories being populated into the form. As it turned out, my test database did not have any categories with the type ADDON_PERSONA (themes used to be called personas), which is an internal constant. By adding this, I was able to create my new theme. The next step was to review my own submitted theme. I added my test user as an admin user in the database so that the proper privileges were assigned. Upon attempting to edit my submitted theme after approval, I found that I was successful with no hesitation. Chalk another one up to “could not reproduce”.

Despite being slightly frustrated, I can’t help but think that being unable to reproduce certain bugs is not a total loss. Every time I attempt to reproduce a bug I end up learning a lot about the codebase as a result. If nothing else, this should make it much easier to solve future related problems!

Success At Last

I continued onward by scanning the list of available Add-ons bugs and I came across one that seemed like it would be relatively easy to fix (and at this point that is what I needed). The bug involved attempting to set an add-on’s type to “Any”. From a comment on the bug, it was determined that “Any” is not a valid add-on type and thus it should not be available in the drop down menu. A dictionary of valid add-on types was being passed into Django’s ChoiceField. In order to get rid of the ADDON_ANY option I had to simply iterate over the available types and add each one to a new array of key value tuples unless it was the ADDON_ANY option. Since the change was so trivial I opted not to add a test (partially because I was unsure of where it should live) but I will have to see how that goes over one someone performs the review. I opened the pull request for this bug here.

After finally getting a pull request open I decided to keep the streak going and look for another bug to handle. I came across another Add-ons bug that seemed interesting. The reporter described that whenever a single whitespace character was entered into the search box on the Add-ons site, the search would become unavailable. I thought that this behaviour was pretty curious so I opted to look into it further. I first tested the production Add-ons site and sure enough the problem was happening there. I also tried entering nothing in the search box and learned that the search did function properly in that case (by just displaying all search results). I switched over to my development environment and I was able to mimic the production behaviour with ease.

The Add-on’s site uses Elasticsearch to power their search backend, which is scalable full-text search engine. Its great selling point is that it is fully distributed so that you can use multiple hosts to handle the entire load. In my development environment, I could see that Elasticsearch was failing to properly parse the search result when only a space character was entered. I modified the search form so that all whitespace surrounding a search term would be trimmed. This would mean that anytime a search was performed with only space characters, it would be treated as if no search query was entered. I attempted to run the suite of related tests but found that all of the tests related to Elasticsearch were being skipped. Through some digging I found that I was required to enable a flag inside my settings file:

RUN_ES_TESTS = True

The tests that use Elasticsearch are significantly slower than those that do not (since they must interact with an outside system), which is likely why they are disabled by default. Once the existing tests were running properly, I added a new test to ensure that a 503 error was not thrown upon searching for space but rather a 200 response would be returned. I then submitted a new pull request for my patch here.

Although I hit a few stumbling blocks earlier in the week, I am happy to have opened a couple more pull requests to the Zamboni project. After just passing my semester halfway point, I am looking forward to seeing how much more I will be able to accomplish as the term wraps up.


Written By

Andrew Halligan

Published March 1, 2014