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

201–210 of 336 posts

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

#201

Post by cpursley »

sofixa wrote: post #154
ineedasername wrote: post #117

Earlier quoted context omitted.

Yes-- at my local suoermarket a small purchase will just go through, while a larger one (~$25 is the threshold) requires a signature.

A signature ? I'm sorry, are you from the past? Joking aside, I don't see how a signature is of any use provides your card is supposed to have yours on the back, so anyone having your card has your signature too. PINs have been a thing since I've had a card (2011), and I don't see why anyone still relies on signatures for card authentication. The way things work in developed countries is the following - payments unde…

It's not a joke, US payment systems are hot garbage (as are bank apps). Much if the rest of the world has been doing contactless payment for 5 years already.

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

#202

Post by egeozcan »

munificent wrote: post #32
dragonwriter wrote: post #30

Earlier quoted context omitted.

> Mongoid follows versioning guidelines as outlined by the Semantic Versioning Specification, so you can expect only backwards incompatible changes in major versions I will note that this reverses the direction of implications. In SemVer, you should expect breaking changes only in major versions. (All version changes with breaking changes should be major, but nonbreaking changes can occur in major or minor versions.)…

I'm guessing the sentence they wrote is just a consequence of English not being the author's primary language. I frequently see ESL speakers get adjective and adverb positions wrong in ways that unintentially change the meaning. Even skilled English speakers make mistakes here because English is both very permissive about word order, but also tends to give different shades of meaning to each other. "Only" is a pernic…

Reminds me the "any cars that have been lapped by the leader will be required to pass the cars on the lead lap and the safety car" clause in the Formula 1 racing regulations (article 48.12), which got a lot of attention after the last race in the season.

Red Bull Racing argued that in that sentence "any" doesn't mean "all". As a non-native speaker, this is just mind games for me.

More reading: https://english.stackexchange.com/questions/580131/does-any-...

If you really have a lot of free time, interest in regulations, F1 AND the English language, this deep dive can also be interesting: https://www.reddit.com/r/F1Technical/comments/rkv633/unpacki...

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

#203

Post by gedy »

stouset wrote: post #194
emodendroket wrote: post #182

Earlier quoted context omitted.

Ultimately this is why I don't like to work in Ruby. You can just never trust any line of code between the gem updates, the unhelpful signatures, the overreliance on hashes everywhere, and a million different levels of mix-ins and indirection. Yeah, it's expressive, but how much time are you really saving once you consider all these maintenance headaches?

This exact problem could have happened in any language. Literally zero of it has to do with Ruby or the ecosystem.

No, this is particularly bad in Ruby. Many languages, esp. compiled do not have the same issues.

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

#204

Post by mattigames »

stefan_ wrote: post #37
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://…

The changelog for 7.1 ( https://github.com/mongodb/mongoid/blob/master/docs/release-... ) even explicitly call this out as a breaking change: Breaking change: In Mongoid 7.1, when condition methods are invoked on a Criteria object, they always add new conditions to the existing conditions in the Criteria object. Previously new conditions could have replaced existing conditions in some circumstances. Ironically they a…

I mean, they care enough to mention it in the changelog, if they cared even less they wouldn't mention it there (not condoning any of their behavior, just pointing that out)

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

#205

Post by GreenWatermelon »

x3n0ph3n3 wrote: post #3
fiddlerwoaroof wrote: post #2

This sort of behavior change in a dependency would make me blacklist the dependency.

I shun everything MongoDB because of how immature its engineering culture is.

But, is web scale?

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

#206

Post by forty »

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.

I agree with the 3 lesson, but here I find the main problem is the lack of test. And weirdly the author doesn't seem to have noticed it.

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

#207

Post by GreenWatermelon »

jacquesm wrote: post #26
Beltiras wrote: post #15

Earlier quoted context omitted.

I can't explain for the other user but I'll tack on my own little horror story. I once got the task of porting something written for early nodejs that used MongoDB as a backend to Django. The app had been developed by a contractor and had many iterations of the data layer. I had to somehow make sense of how to make that all fit in a relational database. The changes made were not documented at all and I didn't have ti…

RDBMS are the solution to many of the problems that these 'modern' systems have, but it isn't cool. Someone joked that the wave of the future will be SQL, and that those start-ups that use it will believe that they have superpowers over the ones that don't. Transactional integrity, complex queries, constraints, what's not to like?

This video should speak to you

https://youtu.be/b2F-DItXtZs

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

#208

Post by mad182 »

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://…

Wow. This is really awful, would be bad idea even for a major version. Shipping it in minor version is insane. It's the worst kind of breaking change, not just resulting in error or exception, but can easily lead to loss or damage of data and unexpected behavior without anyone immediately noticing.

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

#209

Post by kortex »

brian_cloutier wrote: post #178
kortex wrote: post #119

Earlier quoted context omitted.

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 hav…

Yeah, they might have just had unit tests with mocked db, or there wasn't enough combinatorial variety. It's insufficient to test the lack of double billing - you have to specifically induce a race condition, assert the race occurred, and that the interlock prevented double spend. It's tricky. Personally I'd try to engineer around race condition entirely, like some scheme with tokens and pagination.

I agree, this sort of thing seems like it should be extra-well covered, but, y'know, move fast and double charge folks.

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

#210

Post by vishnugupta »

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.

> 2. Don't use high level ORMs.

Seconded. I prefer high level abstractions in general. However when it comes to ORMs; I wouldn't go anywhere near them. Admittedly there's a sweet spot where you could hand-pick ORM libraries such that you hand-code the queries and they only map query results to your objects. But to achieve that you need to wade through documentations and some undocumented APIs. So developers usually go all-in on ORMs. A big mistake.

Post reply on HN