"It stopped working"

I'm on a call with our client where they're telling me that something in our code broke login access on the web.

I reply in a very empathetic manner.

"Well, when doesn't it break? did it exactly stop working?"

Phew. Almost let that one slip out.

"We just noticed it a few days ago. Thankfully this isn't happening in production. It's only in UAT, but we need it fixed to do further tests for other tickets"

"Alright, I'll take the case!" I said, putting on my Sherlock Holmes hat.

Investigating and debugging code has weirdly become one of my favorite activities to do on projects. There's nothing like figuring out weird problems with code and coming up with a one-character PR to fix it.

The problem seemed to have to do with a token we were decrypting. Something was causing issues and it was creating a specific console error. Seemed like the result of the decryption was just ending up with garbage code.

So... what's the first step in debugging something like this?

The first thing I did was think – it's working in production, but not UAT. So... what changed? Let's check that.

Plot twist #1:
Nothing was different.

Okaay, weird. It's been a while since any files were modified. So... something else must be the issue.

What if I... ran the code in production locally and compared it to how the code ran in UAT? Maybe there's some difference there?

After 10 minutes of setting all that up I found...

Plot twist #2:
There was one line from a library generating a different key than expected

Eureka! Now, what does that line say?

It's... a library function call from the library we use. It's using a function called PBKDF2.

(For nerds who want to know but don't want to google: it's a "key derivation function with a sliding computational cost, used to reduce vulnerability to brute-force attacks.")

For some reason, that function is returning something different between environments despite passing them the same info. That's no bueno.

So maybe the library installed has a different version between the environments? I go check the package.json and...

Plot twist #3:
The library versions are the exact same. It's 4.2.1

Something isn't making sense. There's something fishy going on here.

So I googled it for a while to see what I can find 🤷‍♂️

I came up with a StackOverflow issue somebody found about that library. And then...

Plot twist #4:
I found the issue and it made me angry >:(

I took a look at my package.json again and noticed this little character in front of the version number: ^

Then I remembered what it meant – It automatically updates both minor and patch updates whenever you run npm install / yarn install. So guess what?

UAT had the latest minor version of the library. Production didn't. That's the difference.

But wait, these are minor versions! What could change between them? I thought one couldn't introduce changes that could alter the output behavior of core library functions in minor updates.

That was, until I remembered the famous Sherlock Holmes quote:

"When you have eliminated the impossible, whatever remains, however improbable, must be the truth"

Yes, it totally changed. 😒

The default values that the PBKDF2 function call had between minor versions had changed, (switching the algorithm from SHA1 to SHA256 and changing the number of iterations) which caused it to return different values when decrypting. So yes, absolutely, it changed in minor versions.

Now granted, this was made for security reasons, to improve the default security of tokens using that function. So it made loads of sense.

Doesn't mean it didn't make me angry 😂

So yes, today I absolutely, positively made a PR that just removed the carrot ^ symbol in our package.json.

That was only possible because of my approach to asking the right questions at the start (Otherwise I would have taken a lot longer to figure it out)

​And I'm making a product that will help you think critically and ask project-saving questions. It's a pre-sale right now and I appreciate everybody who decides to check it out 💪