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

21–30 of 336 posts

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

#21

Post by noneeeed »

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, irrespective of how minor they are, I've been bitten by enough "minor" changes. But I treat Mongoid as an active adversary who is setting out to break things with every update.

It's the complete opposite approach to that of the Rails core team and those that work on ActiveRecord (as the nearest equivalent to Mongoid). Changes to Rails core are always well flagged with really good advance warning of upcoming breaking changes, frequently with deprecation warnings several versions in advance. There just seems to be a core culture of thought and care towards their users.

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

#22

Post by lmeyerov »

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 :)

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

#23

Post by jacquesm »

If every breaking change would lead to more income we'd be doing so well. What on Earth were they thinking, to change the default behavior for something that is in production use for so long. This was monumentally stupid, even if it is a windfall for the OP, it could have easily gone the other way. And props for figuring out what it was, likely there are some other people scratching their heads about this.

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

#24

Post by ricardobeat »

BlackFingolfin wrote: post #20
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…

To be fair, the your second link points to the documentation of an ancient version; the new docs don't seem to mention semver (I still don't think what they are doing is reasonable, but ...)

That link is reachable from their home page right now, under “Upgrading”.

EDIT: just noticed the docs I found via Google are marked as “old” in the URL: https://mongoid.github.io/old/en/mongoid/

Are you suggesting they dropped semver in between these releases?

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

#25

Post by jacquesm »

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…

This is part of the TCO of any major software project, kudos for getting it right, that's a very mature process you have there.

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

#26

Post by jacquesm »

Beltiras wrote: post #15
gqewogpdqa wrote: post #4

Earlier quoted context omitted.

Can you explain?

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?

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

#27

Post by radicalbyte »

gqewogpdqa wrote: post #4
x3n0ph3n3 wrote: post #3

Earlier quoted context omitted.

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

Can you explain?

MongoDb are infamous for lying about their capabilities. Just search hackernews and you'll read all of the horror stories.

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

#28

Post by denotational »

> Our app for some reasons was creating new subscriptions from old accounts that was canceled or disabled a long time ago.

If I cancel or disable my account for a service I don't expect them to be able to charge me money in the first place!

Are they keeping card authorisations (or direct debit mandates, or whatever other mechanism) for customers that don't even have an account with them any more?

That sounds like an... ...interesting way to do business, but perhaps I'm misinterpreting this.

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

#29

Post by asdfasgasdgasdg »

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 :)

I don't think you can ever make a breaking change like the one described. There's just no way to audit the correctness of all your users after that change. You need to leave the old thing with the old behavior and only add the new behavior to a new thing.

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

#30

Post by dragonwriter »

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…

> 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.)

This is not the same as expecting only breaking changes in major versions. (Which would mean all changes in major versions should be breaking, nonbreaking changes cannot occur in major versions, and breaking changes might still occur in minor versions.) .

Post reply on HN