Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A routine gem update ended up creating $73k worth of subscriptions

serpapi.com

Post reply on HN
Print view View original

171–180 of 336 posts

Re: A routine gem update ended up creating $73k worth of subscriptions

#171

Post by 999900000999 »

kurtbuilds wrote: post #138

Three easy lessons: 1. Don't use MongoDB. 2. Don't use high level ORMs. Stay (reasonably) close to SQL. And yes, it should be SQL. Almost certainly Postgres. 3. Especially don't use Mongoid.

Even though I hate SQL with a passion, I agree with this 100%.

Mongo is a nightmare when things get more complex, document based DBs don't work well. It's hard to say why, but strange things tend to happen

Ether use something like Firebase which manages everything for you, I use Firebase extensively for almost all of my side projects.

It's basically magic. I'm so hooked I ended up using Firebase even though I needed to talk to AWS apis as well. Not fun...

Edit: I would NOT use Firebase for a corporate project, there's a very strange feeling of not really being in control

Re: A routine gem update ended up creating $73k worth of subscriptions

#172

Post by dudeinjapan »

welder wrote: post #120

This would never have happened had they used a real database instead of Mongo.

This comment isn't helpful; this was entirely an ORM-layer API change and had nothing to do with the underlying DB. The exact same bug could have happened in a SQL ORM.

Re: A routine gem update ended up creating $73k worth of subscriptions

#173

Post by dasil003 »

This title reminded me of a bug I experienced many years ago upgrading the Money gem where they introduced the subunit_to_unit ratio (instead of assuming it's 100). This caused our Japanese customers to be charged 100x what they were supposed to.

Re: A routine gem update ended up creating $73k worth of subscriptions

#175

Post by sam_lowry_ »

radicality wrote: post #143
kurtbuilds wrote: post #138

Three easy lessons: 1. Don't use MongoDB. 2. Don't use high level ORMs. Stay (reasonably) close to SQL. And yes, it should be SQL. Almost certainly Postgres. 3. Especially don't use Mongoid.

Could you comment on why you recommend Postgres (vs say mysql)? I know mysql well but haven’t had much exposure to Postgres.

Postgres implements the SQL standards however awful they are.

MySQL is a bunch of different engines that share a meaningful subset of SQL.

Somehow, Postgres got more popular lately, probably because it makes migrating from Oracle easier.

Re: A routine gem update ended up creating $73k worth of subscriptions

#176

Post by plorkyeran »

ineedasername wrote: post #125
andrew_ wrote: post #73

The mongoid repository ( https://github.com/mongodb/mongoid ) doesn't have issues turned on and instead points people to JIRA. That's one way to avoid users reporting issues like this - I'd see JIRA and "nope" right out.

Is JIRA that bad even for just logging an issue? Or do you nope out of the dependency?

At the minimum it's another account you have to register. The more Jira-specific problem is that making drive-by issue reporting frictionless is an extremely low priority for Jira (or for the people who choose to use Jira), and there's often going to be a bunch of confusing steps required.

It also just signals that they aren't really that interested in hearing from users. People who crave feedback and bug reports go to where the users are rather than making the users come to them. Even if they use Jira internally, they'll do things like monitor stack overflow and provide support on Github.

Re: A routine gem update ended up creating $73k worth of subscriptions

#177

Post by Gigachad »

ricardobeat wrote: post #8

That sounds like a major, incredibly dangerous update to the DB driver. Their 7.1, 7.2, 7.3 versions seem to all have breaking changes [1]. Yet they are in obvious violation of SemVer expectations, which they declare to follow [2]: > Mongoid follows versioning guidelines as outlined by the Semantic Versioning Specification, so you can expect only backwards incompatible changes in major versions [sic] [1] https://docs…

Tbh when you work with ruby to have to assume everything could break with any update and just unit test the shit out of everything. Of course it’s easy to miss something, but unit tests could have caught this issue.

It's still just really bad work from the gem developers though. Ideally you shouldn't ever drastically change the behavior of a method. Just introduce it again with a new name and remove the old one. Yeah it might not be as nice, but it avoids triggering $73,000 worth of incorrect transactions.

Re: A routine gem update ended up creating $73k worth of subscriptions

#178

Post by brian_cloutier »

kortex wrote: post #119
Retric wrote: post #93

Earlier quoted context omitted.

Shipping something with zero testing is always crazy. Even a minor bug fix in a library can expose a critical bug in your own code.

There's a huge difference between "zero testing" and "we didn't have this particular test case covered because the state space is massive". Lets say you even have "100% code coverage", do you really have a unique case for each possible condition in that query? Often times chaining operators like TFA give "deceptive" coverage results because they mark that whole code path as covered, without verifying the state space…

In the general case you are right, but in this specific case... this test case should have been covered. Even a rudimentary integration test would have caught this bug.

It sounds like the user story is:

- A user runs a query

- The user does not have any queries left in their plan

- They are billed.

- When the user runs the query again they are not billed a second time.

I'm struggling to imagine how the test would have failed to catch this. Maybe it was unit tested but with a database containing just one user? Maybe they got very unlucky and the correct user was randomly chosen?

Re: A routine gem update ended up creating $73k worth of subscriptions

#179

Post by rgoulter »

nefitty wrote: post #36
noneeeed wrote: post #21

We use Mongoid. I treat every upgrade, no matter how small as its own piece of work involving going through the changelogs with a fine-tooth comb. This particular issue got flagged up when we last looked at upgrading. Currently Mongoid upgrades are stalled until we have the time to figure out the impact of some of their more egregious changes. I have a generally low trust approach to all dependency upgrades, irrespec…

I feel spoiled having most of my experience in js, react and node. They like, try really hard not to totally break shit.

Well, except for leftpad.

Re: A routine gem update ended up creating $73k worth of subscriptions

#180

Post by zomglings »

warpech wrote: post #6

Mongoid docs[1] seem to be pretty cool about this change: "As of Mongoid 7.1, logical operators (and, or, nor and not) have been changed to have the the same semantics as those of ActiveRecord. To obtain the semantics of or as it behaved in Mongoid 7.0 and earlier, use any_of which is described below." Is it just me or is this one of the most terrible breaking changes in a popular, official library ever? [1] https://…

Seriously, why the fuck not just bump to 8.0.0 or whatever?
Post reply on HN