Below are some of the interesting bugs that I encountered over the course of my software engineering career.
process.env undefined?
I have a test file that looks like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
const myFunction = () => { if (process.env.MY_ENV) { // doSomething(); } } afterEach(() => { process.env.MY_ENV = undefined; }); it('called when MY_ENV is set', () => { process.env.MY_ENV = 1; // assert doSomething called }) it('not called when MY_ENV is not set', () => { // assert doSomething not called }) |
The idea is that I want to test if the condition on the environment variable MY_ENV is working correctly. However, the second test when process.env.MY_ENV is undefined keeps failing. I tried to print out the value of process.env.MY_ENV, but it was showing “correctly” as undefined.
After debugging for half an hour, I decided to take a look at process.env directly. And I was shocked by what I found: process.env.MY_ENV is actually the string ‘undefined’ instead of the value undefined. So that’s why when I printed it out, it looked correct. It is completely unexpected that the assignment of undefined does not work for process.env when it works for everything else I had tried so far.
It was indeed raised as an issue in Node.js repo. And subsequently, there was documentation specifically added for this weird behaviour.
JavaScript / npm / Node
- Module resolution bugs
- hoisting and peer dependency
- npm vs yarn
- checking if a package is installed
- Node bug
LSEP Character on HTML in Windows Chrome
After adding a new post for my company’s engineering blog, I discovered that it is rendering a weird character on live website (at the end of some lines):
LSEP character
However, we didn’t notice that character when editing markdown in macOS.
After digging some resources, we found out it only shows up in Windows systems. The interesting thing is that even we cannot see the character in macOS, we can still select the character using the keyboard arrow keys and do a replace operation in our markdown files (thanks to yuan3y).
So we did a replace and fixed it with a PR that shows no changes on macOS: https://github.com/grab/engineering-blog/pull/16
Increasing Number of Repeated Logs – Sept 2017
When I was writing a new service in our Rails server to talk to another service, something strange happened. I noticed that the same log for requests sent by the service were getting printed to the console repeatedly for more than 10 times. And as time goes by, the number of repeated logs seems to be increasing.
When I first tried to approach the issue, I thought, “Maybe I didn’t follow the correct format as the other services?”
So I changed my new service structure to be exactly the same as the other services and tried sending request again. The log still appear multiple times. Maybe the hot reloading is not working? So I restarted the server and tried again. This time, the issue disappeared. “Great!”, I thought the issue was fixed.
However, a few hours later, it started happening again. Now it is printing duplicate logs 4 times, less than the initial 10 times, but still not solved.
Could it be due to multiple rails consoles that I opened? I restarted the server, tried sending request, opening another console, sending again, the log is only printed once.
Then when I moved on to write some code and come back to check the log a few hours later, it is getting printed multiple times again.
I decided to do some logging using ruby puts method in the code to check where the multiple log printing originates from. After adding logging and restarting the server, I once again moved on to other things.
As expected, I see 2 repeated logs printed, but the code that calls the logger was only called once, so it must be a problem of the subscriber.
The moment of truth came when I removed my puts from the code. After sending a request, I see 3 repeated logs, one more than the original.
Following this, I tried undoing the removal of puts, and (un)surprisingly, now there are 4 repeated logs.
So it is the editing of the file that caused the log to be printed repeatedly? Then I came to the realization that it must be the hot reload. Something during the hot reload triggered the subscriber to re-subscribe.
Indeed, after inspecting the service, I noticed that the code to subscribe to logging event was outside the service class. So it is getting executed every time when the hot reload is being carried out.
Case closed.