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

321–330 of 336 posts

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

#321

Post by lamontcg »

xavdid wrote: post #318
lamontcg wrote: post #121

Earlier quoted context omitted.

A big part of the problem with SemVer is that "breaking changes" is subjective and there's always the xkcd spacebar heating problem. The flip side of most breaking changes that are released is some software developer who either wasn't experienced enough to imagine that the change would break someone or else they're dealing with a very hard problem that they're trying to solve and the break change was collateral damag…

> A big part of the problem with SemVer is that "breaking changes" is subjective I don't think that's true. I've always thought a breaking change is defined in broad terms as "the public API surface, runtime, and output". Given that, each of these would be a SemVer major: * remove a publicly-exported function * public function changes order of arguments * drop support for an old version of the language * a function c…

That is a nice neat and tidy way of thinking about changes. The messy details are things like "oh the default options result in a massive security hole, they need to change immediately". There's also a messy medium ground where behavior changes and its just a question as to if anyone is dependent upon that behavior. It was wrong when it was implemented, never documented, but has a currently defined behavior that most people don't want -- unless they happened to find it and use it and work around it and they'll be broken by the switch. This is the realm of things like the undefined behaviors of the C standard which are compiler-dependent. Any sufficiently complicated API will have those all over the place. You can argue that APIs should never have those kinds of undefined standards, but in reality everyone does shoddy work and people accept PRs that they shouldn't (and the flip side of trying to be careful is people yelling about open PRs that have been stalled for months/years trying to sort out a sufficiently robust solution).

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

#322

Post by caspar »

mickotron wrote: post #100
mchusma wrote: post #95

Stripe also bears some responsibility here, as they don't support production testing, so it's impossible to have a test suite checking for charge related behaviors in production. If you use stripe, please contact them and request this long overdue feature. (I do not think that is the primary issue, but it does not help)

Why not test with a stub? Issue would have been picked up in testing even without Stripe integration.

Exactly, https://github.com/thoughtbot/fake_stripe works well enough for this sort of thing.

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

#323

Post by iamleppert »

Don’t deploy untested code to production. The fact that it’s a dependency doesn’t excuse a proper code review.

It is ironic to me that software teams have code review processes and seem to trust each other less than random people they have never met on the internet. Every new dependency, you need to read the source. Read it completely.

Every new change in every dependency needs to be reviewed as well. I’m a big fan of forking all dependencies and using only those forks in my code. Then, do upgrades via standard rebase or pull requests on that fork.

If you have dependencies that are too large to do this with your time, you probably should avoid them in the first place.

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

#324

Post by jchw »

stouset wrote: post #307
jchw wrote: post #211

Earlier quoted context omitted.

Certainly it has something to do with the ecosystem, if the most popular MongoDB driver in the ecosystem is making breaking changes in minor versions. That said, strong types can be a godsend for catching accidental breaks, even if it wouldn’t necessarily have helped here. A strongly typed language that has a more disciplined ecosystem is less likely to run into these kinds of issues. It’s one of the tradeoffs you pi…

> Certainly it has something to do with the ecosystem, if the most popular MongoDB driver in the ecosystem is making breaking changes in minor versions. Am I to believe that you hold every other language to this same standard? A single maintainer of a reasonably popular project makes one boneheaded decision in a release, and that's enough reason to denounce the entire ecosystem? > That said, strong types can be a god…

I am using the Wikipedia definition of 'strong' vs 'weak' typing.

> Generally, a strongly typed language has stricter typing rules at compile time, which implies that errors and exceptions are more likely to happen during compilation. Most of these rules affect variable assignment, function return values, procedure arguments and function calling. Dynamically typed languages (where type checking happens at run time) can also be strongly typed. Note that in dynamically typed languages, values have types, not variables.

Just out of curiosity, exactly what do you even think weakly typed could mean by your own definition of it?

No need to address the other points, because we're talking about anecdotes and not scientific data. Yes, I'm using a single data point as an example about a feeling I have to justify my opinion.

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

#325

Post by jacquesm »

klyrs wrote: post #311
jacquesm wrote: post #49

Earlier quoted context omitted.

Yes, now imagine the other way around. How are you going to tell your users that you screwed up and will need to invoice them either again, or much closer to their next charge. Or maybe much later still if you don't spot the error right away. Note that my comment isn't about the OP, but about the root cause of the breaking change: the driver.

Well, you described it as a "windfall for the OP" which really isn't accurate. Accidentally charging customers is a nightmare, and payment processors (rightfully) see large numbers of chargebacks as a red flag which can result in frozen funds / locked account. I'm not sure that the gem authors are benefitting from this either; it's open-source and they've probably lost users as a direct result of this article.

See the title of the article.

That they ended up returning it is good but either the amount was meant to have some kind of significance and before they returned it they received it.

I'm well aware of the effects of various kinds of risks to merchants.

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

#326

Post by phendrenad2 »

The code is fine, you're publicly chastising yourself over it for no reason. Mongoid had bad API semantics, and you did what you needed to do to make your code work. Then, you got rug pulled by a minor version update when they said "oopsie, we think these semantics make more sense!".

There might be an argument to make that your test suite could have caught this, however.

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

#327

Post by phendrenad2 »

ljm wrote: post #243
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?

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…

Yes, this is just part of life. Most open-source developers go well beyond the technically-correct "I don't owe you anything" stance and actively try to help their users, which includes adhering to SemVer, and trying to do more work so that the user doesn't have to.

However, you can't rely on this. Many open-source projects fill a niche and become popular when it isn't the intention of the author. This causes a disconnect where the users expect the project to be for them, when the project is really for the author. Mongoid seems to be more in the former category (for the user).

Because some libraries are badly managed, you need to audit all of them.

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

#328

Post by Xavdidtheshadow »

lamontcg wrote: post #321
xavdid wrote: post #318

Earlier quoted context omitted.

> A big part of the problem with SemVer is that "breaking changes" is subjective I don't think that's true. I've always thought a breaking change is defined in broad terms as "the public API surface, runtime, and output". Given that, each of these would be a SemVer major: * remove a publicly-exported function * public function changes order of arguments * drop support for an old version of the language * a function c…

That is a nice neat and tidy way of thinking about changes. The messy details are things like "oh the default options result in a massive security hole, they need to change immediately". There's also a messy medium ground where behavior changes and its just a question as to if anyone is dependent upon that behavior. It was wrong when it was implemented, never documented, but has a currently defined behavior that most…

> It was wrong when it was implemented, never documented, but has a currently defined behavior that most people don't want

That strikes me as exactly the sort of guarantee that's _not_ made by semver. You can rely on that behavior, but then you have to check against every patch version, because that's exactly the sort of thing that could change out from under you. Maintainers shouldn't worry about breaking this case- they never promised to support it in the first place.

I think a lot of those cases should be a major version change, and that's totally fine. We _should_ minimize the number of breaking changes to code people depend on, but sometimes the best fix to the (totally reasonable) situations you outlined above is to make a new major version. Users will have to make changes to upgrade (instead of just bumping the versions), but it won't change out from under them. Some docs about what's changing, why, and how to migrate your code go a long way here.

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

#329

Post by lamontcg »

Xavdidtheshadow wrote: post #328
lamontcg wrote: post #321

Earlier quoted context omitted.

That is a nice neat and tidy way of thinking about changes. The messy details are things like "oh the default options result in a massive security hole, they need to change immediately". There's also a messy medium ground where behavior changes and its just a question as to if anyone is dependent upon that behavior. It was wrong when it was implemented, never documented, but has a currently defined behavior that most…

> It was wrong when it was implemented, never documented, but has a currently defined behavior that most people don't want That strikes me as exactly the sort of guarantee that's _not_ made by semver. You can rely on that behavior, but then you have to check against every patch version, because that's exactly the sort of thing that could change out from under you. Maintainers shouldn't worry about breaking this case-…

We do major version bumps on a yearly cycle and people get stuck on 8 year old versions and won't upgrade. Its easy to say that integers are free and limitless, but constant major version upgrades are something that people won't tolerate one way or another either.

And you have to understand that the people making these decisions make dozens of them for every single release, and when they make category mistakes that is how you get breaking changes released early. Every single bug when looked at in isolation looks obvious what should have happened given hindsight bias.

And I just don't think open source software, that isn't corporate backed in one way or another, should ever go 1.0 and it should stay 0.x.y and go ahead and break compat every 3-6 months or so as necessary. The cost of SemVer and trying to get it continuously correct on every single patch is a large tax.

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

#330

Post by henry700 »

montblanc wrote: post #219
henry700 wrote: post #134

Earlier quoted context omitted.

Not if you follow the One True Way of Unit Testing (tm) where the Mongoid lib would have been mocked away, and the test would pass :) Integration tests might've done the job here.

You dont mock the db layer, i dont do that at least, hell no. Let the db be hit, check that the records it returns make sense. Thats how I roll at least.

Didn't want to aim at you with the reply, just remembered the collective delusion of 100% coverage unit testing zealots and how this would ironically fail to catch this.

You'd be surprised how far people go to shoot themselves in the foot.

Post reply on HN