Get The Most Out Of A Tiny Bug

Almost no software is perfect. Bugs always happen and sometimes it requires endeavor to fix them. At first you may panic just as you see a cockroach in the kitchen. Then you calm down and start thinking, tracking and struggling with it which may lead to real frustration. Afterwards when you’re finally able to fix it, you feel like a hero just like after killing that cockroach! But it’s not the end. You’re definitely willing to see less bugs like that in the future or to be more ready for the next time. So how about gathering some useful information after each bug fix, to answer main questions such as what is a bug’s reason, what’s its impact, how can a bug be prevented from occurring or how could we get informed of it sooner?

Here at Sanjagh, we have come up with the idea of writing a document for almost every bug fix. This document consists of the answers to above questions or any other useful data we can gather. Below is a case study of a real issue that has been resolved and documented as mentioned.

The Case Study

In the process of submitting a request for service in sanjagh.pro, the customer goes through some steps to specify the details of her request. To have a better user experience we designed a progress bar to indicate the current progress of the customer in completing steps of a request. If the customer is already logged in, the process finishes at the last service specific question otherwise there are two more additional steps for customer login. There was an old low priority issue of not counting these two additional steps in total steps of the progress bar, resulting in actual and rendered progress mismatch. This issue was fixed by enumerating total steps based on the customer session fetched from the server and passed to the step manager component. The session was of type optional, some(value) for the logged in user and none otherwise. The job got done and it was reviewed and tested manually and everything seemed fine. But after deployment, it led to a more critical bug….

What was the bug?

The session was undefined sometimes. Meaning that in some circumstances, there was no value assigned to the session. In other words the request for fetching the session was not performed before its usage and thus causing it to be undefined.

Why did this bug happen? How to prevent similar bugs?

This bug was raised from using bad practices in handling api calls. Speaking in React, the request for this data was performed in componentDidMount of a component and the data was accessed directly from redux store in another component’s render body. So if the render body of this component was called before componentDidMount of another, the bug would show its face! And unfortunately this happened in a way that we didn’t think about! Only the users who visited sanjagh’s landing page via Google Adwords link, faced this issue. Because the url used for Google Adwords has a query part to render the modal via which customer submits an order, as soon as users get to the page. In this case the render body of the component which accessed redux store and used session data, was performed before the componentDidMount of the component who requested it and it caused the error.

Generally we should be careful in calling asynchronous functions such as data fetching. We have to be sure that the request for the data we are going to use has been performed and the result has been fetched before doing any other actions on it. Thus to prevent this kind of error one solution is to use a reusable procedure for data fetching. Something that has been implemented and tested before and wherever we use it, we are sure that it works well.

What was its impact?

Since the javascript code stopped running, pages on which this bug occurred lost their interactions totally (no button was working anymore!). Only the users who landed from our Google Adwords campaign were infected by this bug so we can conclude that it has reduced our orders by conversion rate * number of mentioned users .

How could we get informed sooner?

This bug was not seen during the manual testing process. In general, manual testing may include error and it’s not suitable for large scale applications. A better solution for testing to find this kind of defects, is automated end-to-end testing that allows us to test lots of different cases.

But what if for any reason, the bug survives from the test? How can we arrest it before it makes more damages? We need a monitoring and error tracking tool. Currently we are using sentry for this purpose. After checking sentry’s panel, It was figured out that sentry had reported this bug after deployment but nobody had noticed and it was simply ignored. Now we have to talk about using these kinds of tools more precisely and more effectively in our tech team.

That was an example of a bug fix documentation at Sanjagh. It has helped us to enhance our testing process, identifying bad practices, preventing similar bugs from happening, using better tools and using tools better. Each tiny bug can give us a lot of insights to improve our development process, only if we ask for it!