Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It could be an index error or a misuse of references, where product B is supposes to be product A + 10.

It could be that some local taxes or fees comes out to $10, and the client code does `price += taxes` on page load.

There could be code to round up to a $10 increment, and then subtract 2 cents so the prices are all $X9.98, but the rounding logic is incorrect. Since this is JS, they will be using floating point prices. That is a minefield in itself.

I'm not saying it's definitely a bug. But it trivially could be.



Verification would be this same test but seeing if the price persists into the "cart" or further down the checkout / shopping process.


Why do you need to keep state here? I can see calculating the prices dynamicly, but why save and the reuse the result?


They could be using some node.js framework they don't understand that is silently persisting data.


Especially if they are using isomorphic JS. Globals / singletons are very dangerous when the JS runs on both the server and client.


* Pull data from API for pricing, later add caching

* Modify value to give local amount, not realising it's modifying a cached value

* Never test refreshing doesn't change the price


Caching.


>> It could be an index error or a misuse of references, where product B is supposes to be product A + 10.

But why would ANY price be determined in part by the users browser. It gets it right the first time, so why would page reload do anything different? This makes no sense.


It makes no sense, because it's a bug. Why would one package double in price, but the others not change?

> gets it right the first time,

Maybe, you don't know.

It may be adding $10 the first time too.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: