My internship is coming to an end and I think my boss is testing my limits.

So, in the beginning of this week, he assigned me a non reproducible bug that has been causing trouble to the whole team for months.

Long story short, when we edit or create a planned order from the backend, once in fifteen, a product is added to the list and "steals" the quantity from another product.
Everyone in the company has experienced this bug several times but we never got to reproduce it consistently.

After spending the whole week analyzing the 9 lines of JS code handling this feature, reading tons of docs and several libraries source code. I finally found a fix by "bruteforce testing" with selenium and exporting screenshots, error logs and snapshots of the html source.

This has been intense but was worth the effort, first, I fix a really annoying bug and second, I learned a lot of things and improved my understanding of Javascript.

Please don't pull a 'nvm fixed it' on us!

Explain what the issue was please :D

@alexbrooklyn @TheCommoner282
@irene
Okey, basically, we have a button used to add a new product line in the order. The product line contains a select field (for selecting the product), a number field for the quantity and a number field for setting a custom price.

All those fields are generated by the backend framework (RoR) and are stored in a data attribute on the button (This is not ideal but I have to work with the present code base).

When we click on the button, we get the markup stored in the attribute, replace the default name of each field and then insert it inside the DOM.

The issue was that we were replacing the name « cart_items[new_entry] » by « cart_items[current timestamp] » in a jquery each loop. The problem is that sometimes there was a single millisecond of difference between the first fields and the second one. That means the server was receiving the product_id field for « cart_items[1234] » and the quantity and custom price fields for « cart_items[1235] » thus returning an error because of the missing fields.

Impossible to spot by the user before clicking the save button and sending the request to the server.

The fix was quite simple, instead of calling (Date.now()).getTime() inside of the each loop, we store the timestamp in a variable before the loop to ensure each field getting the same timestamp.

A really stupid and obvious error but was quite hard to debug and caused a lot of trouble for a very long time (even before I started my internship here)

@AdrienNini why use a timestamp and not just an incrementing counter? If you need to be sure to create a new product, you could start at 0 and decrement.

@Wack Well, in fact, the framework we use already does it for the existing cart items (when we edit the planned order). It's easier for us to add a new line giving it an index equal to the timestamp as it's a unique value. Then when the request is sent to the server, it will just modify the existing records which got modified and create the new ones incrementing the id in the database (as usual).
The timestamps are just used in the front end part and then are converted to the next index value in the DB.

@AdrienNini

I would have just used a UID lib.

Theres a class of bugs where a recent change will occur and the bug will crop up so it'll appear to be from the recent change but in fact the recent change only revealed the underlying bug in code upstream from the changes. Always fun to have to deal with those.