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

271–280 of 336 posts

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

#271

Post by jve »

contravariant wrote: post #135
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://…

Yeah we just changed the meaning of 'or', no biggie. That said I would normally read 'User.where({id: id}).or({condition1},{condition2})' as 'User where id=id or condition1 or condition2' and not 'User where id=id and (condition1 or condition2)'. Though I could probably get used to either, after all you've also got languages like Lisp where 'or' isn't an infix operator either. And doing something with any one of the…

Coming from .NET/LINQ/SQL, I would have assumed the latter. But then again, if I'd ever write ruby, I should have consulted the docs.

But this kind of behavior change at best should have introduced different API.

Crazy to think that someone remotely can alter your query ANDs to ORs. That may very well destroy your database data and a whole lot of pain to rollback.

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

#272

Post by ljm »

newaccount74 wrote: post #259
ljm wrote: post #243

Earlier quoted context omitted.

We're just trading anecdotes at this point but I can't say I've encountered the same problems over the past decade of working with it. That's generally because of limiting dependencies, but also because it's a good idea to peek at the changelog or release notes when bumping the minor or major version. TFA doesn't mention or acknowledge this aspect of the issue, but it did surprise me that they considered a version bu…

It took you 5 minutes to find the info because you knew what you were looking for. Expecting programmers to audit all of their code before a minor update is ridiculous.

'Auditing all your code' isn't the same as looking up the changes for a certain version on its github release page or a changelog page (if it has one).

It's not the responsibility of OSS maintainer to ensure your software still functions after an upgrade if you're not even willing to spend a modicum of effort to hold up your own end of that bargain. This isn't a big ask, it's why there are changelogs and release notes in the first place; they make it so you don't have to audit the code every time the version changes.

If you're not willing to do that and want unattended upgrades for all dependencies, then this is where the 'no warranty' aspect of that OSS license comes in.

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

#273

Post by mattacular »

I trust semver about as far as I could throw it. It's obviously prone to human error and more. Yes, the library maintainers have done something irresponsible, but the onus is ultimately on you as the consumer to test updates. At least give the change logs a good thorough read and make sure nothing that sounds dangerous jumps out at you. Reading the semver string difference is not good enough and this breaking change was actually documented.

I would almost expect there to be problems jumping up 3 minor versions even.

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

#274

Post by mannykannot »

ay wrote: post #266
philwelch wrote: post #181

Earlier quoted context omitted.

It’s kind of like the saying, “all that glitters is not gold”. Gold doesn’t glitter? That makes no sense. English syntax is not mathematical logic. The song, “I Can’t Get No Satisfaction” is not a song about someone who is forced to receive satisfaction.

It’s curious that a Russian version is much more precise: “Not everything that glitters is gold”. (The truly 1:1 translation is “not everything is gold that glitters” but that word order felt very wrong and I believe the change doesn’t change the meaning, does it ?) How does it sound for a native speaker ?

I am a native speaker of English, yet my knowledge of its grammar is almost entirely informal. Having said that, it seems to me that in the 1:1 translation, the object of ‘is’ is ‘gold that glitters’, rather than just ‘gold’, and its subject is ‘everything’ rather than ‘everything that glitters’, and that these are semantic differences, as the intended meaning is specifically about things that glitter. I hope someone more knowledgable can cite the relevant rules here, whether for or against this reading.

To avoid ambiguity (whether actual or merely perceived by me), I might say “Just because something glitters, it need not be gold”, but that is not much of an aphorism!

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

#275

Post by yua_mikami »

It's such an aptly named database. They probably thought they were being funny when they came up with the name MongoDB but it's just sad when people have constant issues with missing data, breaking changes, security misconfigurations because of stupid defaults etc., the list is endless with MongoDB.

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

#276

Post by recursivedoubts »

lmeyerov wrote: post #22
recursivedoubts wrote: post #12

this has to be a major mistake on the part of the library developers it is completely unacceptable to change semantics like this in a post 1.0 minor version

Breaking changes are things, no project is ever done -- ye olde django is still doing big moves like adding async colors, and that's great! But... CHANGELOG.md with BREAKING CHANGE sections and a major version bump, maybe a DEPRECATED lint and runtime warn() ahead of time, and bam, no surprises for professional teams. For more than that, service contracts are things :)

Sure. That's what a major version is for.

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

#277

Post by [deleted] »

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…

[deleted]

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

#278

Post by Retric »

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…

> update your dependencies and ship it based on version numbers alone

The above is zero testing. Update your dependencies and ship it based on version numbers and integration tests is different. In that case as you suggested test coverage may easily have missed something, but there’s moving fast and there’s moving blindly and the second is just wasteful.

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

#279

Post by losvedir »

newaccount74 wrote: post #259
ljm wrote: post #243

Earlier quoted context omitted.

We're just trading anecdotes at this point but I can't say I've encountered the same problems over the past decade of working with it. That's generally because of limiting dependencies, but also because it's a good idea to peek at the changelog or release notes when bumping the minor or major version. TFA doesn't mention or acknowledge this aspect of the issue, but it did surprise me that they considered a version bu…

It took you 5 minutes to find the info because you knew what you were looking for. Expecting programmers to audit all of their code before a minor update is ridiculous.

Seriously? It's eminently reasonable to expect you to know the code you're deploying. Perhaps you're a JS developer. I agree it's incredibly difficult to keep up with the churn there, but in my Elixir deps, the updates tend to be less frequent and more reviewable.

Some deps you can trust the owner and just carefully review the change log. Even that would have caught this issue, though I'm not sure I'd count this gem as trustworthy.

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

#280

Post by driverdan »

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.

TL;DR: Everything has its place, stop implying you should never use use something.

> Don't use MongoDB.

Don't use MongoDB for something that should be in a relational DB. Use it as the document DB it is. Use the right tool for the right job. Mongo and other document DBs have their place.

> Don't use high level ORMs. Stay (reasonably) close to SQL. And yes, it should be SQL. Almost certainly Postgres.

Hard disagree. I've used many of the ORMs in different popular frameworks. They work well, save time, and are especially good for simple queries. They have their place, just as SQL does.

> Especially don't use Mongoid.

Unfortunately it's the go-to Ruby library for mongo. This could be an argument for not using mongo with Ruby. It could be an argument for creating an alternative. But simply saying don't use it isn't practical for many people.

Post reply on HN