The Debug Life at AnyPerk

Being able to debug code quickly and decisively is a crucial skill for every programmer. Here at AnyPerk, we’ve started to document some of the interesting code debugging cases we’ve come across.

Case 1: The Giving Form

At AnyPerk, we enjoy recognizing and giving rewards to each other. Unfortunately, the form we use to send such events was not transitioning correctly after submission. This resulted in hiding any sort of form submission feedback from the user. Thus, the recognition senders, unaware that their requests had been successful, submitted the form multiple times.

Clicking the Share button submits the form, but does not correctly transition to the success page

Frontend or Backend issue?

It’s important to find out which part(s) of the code base the error occurs in. In most cases, the first question we ask is whether the error is caused by the Frontend and/or the Backend.

To figure this out, I usually use the Network section of my Chrome Developer Tools.

Since I know this form submission is a XHR request, I’m going to filter the requests to only have XHR requests.

Filter by XHR network

Finally, before I submit the form, I want to clear the network history so I can clearly see what new requests happen after I submit the form.

Click to clear history

Now, after I submit my form, I can clearly see what happened with the new form submission request.

You can also click on the request for more detailed info

The ‘give’ request seems to have succeeded with the expected 201 status. It doesn’t seem like a Backend issue to me.

Debugging the Frontend

Another Chrome debugging tool I use quite frequently is the JavaScript console.

When I go there, I see this:

The error is the same as in Production, but since I’m reproducing the error in a QA environment, there are also redux action logs

Because we only uglify in the Production environment and I’m debugging on a QA environment, I can simply click on the link on the right side of the console error to take me to the buggy code.

Unfortunately, we are using a build process that translates our written es6 JavaScript code into a somewhat obscure single file of es5 JavaScript. This can sometimes make discovering the source of the error difficult. In fact, the code you see above is actually 3rd party vendor code. As a developer, I would have never seen this piece of code while working on the code base. So where do we go from here?

Debugging webpack’s build

If we scroll up, we can see the webpack’s comment next to the module’s declaration.

Now, if we search ‘1241’, we should be able to see the name of the module.

There will be an underscore prefix added during the build process, but you pretty much have the name of the module

Finding the module

Now that we know what module the error is occurring in, we can search in our code base to see where this module is being used.

Luckily for me, the module is only imported in one location, and is only used on one line.

Let’s fix the issue

After reading the error and looking at the related line of code, it now seems rather obvious what the bug is.

It looks like setHeaderNav, which is being used as a React.js ref callback, is sometimes being called with a null c parameter, causing the Cannot read property '__resizeListeners__' of null error. Thus, changing elementResizeEvent(c, this.setHeaderNavWidth) to c && elementResizeEvent(c, this.setHeaderNavWidth) will fix the issue.

Case closed

For more on employee happiness, please visit: https://anyperk.com/.

To join our team, please visit: https://jobs.lever.co/anyperk.

More on me: https://www.linkedin.com/in/yiziz.