A routine gem update ended up creating $73k worth of subscriptions • Hacker News Board

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

#121

Post by lamontcg » Sat, Jan 08, 2022, 2:34 AM UTC

lordgroff wrote: post #116

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…

Yeah, semver is great, except nobody follows it. The amount of times I have updated minor or even patch releases of packages with things breaking--I have pretty much determined everything in a project stays the same unless there's some pressing need. The worst part is that breakage is often far from obvious, and spending good time wondering why everything breaks when it shouldn't is really really infuriating and make…

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 damage in some edge condition they didn't consider. Many people's breaking changes are someone else's bugfix, and often users fluidly wind up on either side of that condition on different bugs -- screaming about bugs that haven't been fixed for years and then screaming about other bugfixes that broke them.

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

#122

Post by rubyist5eva » Sat, Jan 08, 2022, 2:34 AM UTC

kortex wrote: post #110

rubyist5eva wrote: post #84

Semantic Versioning is bullshit. Even "backward compatible features or bug-only fixes" can completely break your application. With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. -- Hyrum's Law

That's not really the point. There's a gulf of difference between "we patched a CVE and now spacebar-heating is broken" and "we knowingly and deliberately changed the semantics of a query operator in a minor/patch release in a 7.x library in wide production with 3,900 stars on gitub." Semver doesn't mean "guarantee no breaking changes in minor" - that's impossible - and people love to point this out for whatever reas…

The amount of time I had to tell engineers across multiple companies that one cannot just blindly bundle update all of the minor/patch versions of our rubygems without properly testing everything begs to differ.

"It's semver bro"

No.

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

#123

Post by Ozzie_osman » Sat, Jan 08, 2022, 2:35 AM UTC

denotational wrote: post #28

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

It's unclear whether by canceled they mean the account was canceled or the subscription was canceled.

As a user, if I delete my account, I'd definitely expect my payment details gone. However, if I just disable my subscription, I'd expect they keep my payment details on file in case I reactivate.

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

#124

Post by ineedasername » Sat, Jan 08, 2022, 2:36 AM UTC

jjice wrote: post #57

jacquesm wrote: post #26

Earlier quoted context omitted.

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?

It's funny how true that is. Every day I write SQL I'm grateful that I'm on a relational database and not on some hot new nosql system that is both over and underkill for the work I do.

For a while learning my way around a nosql database was on my to-do for professional development list. I won't claim there aren't valid use cases, but once I got around to spending a few hours poking around I quickly realized it would not make my life any easier.

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

#125

Post by ineedasername » Sat, Jan 08, 2022, 2:38 AM UTC

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?

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

#126

Post by fouc » Sat, Jan 08, 2022, 2:39 AM UTC

userbinator wrote: post #72

I wish more developers would abide by the old saying "don't fix it if it ain't broke." It's one thing to update because you know a newer version has fixed a bug you're experiencing, but if everything is already working as you'd expect, IMHO you're just asking for trouble. There's a reason a lot of the infrastructure systems that many people don't even know about --- until something breaks --- hasn't changed in litera…

Unfortunately if you don't update the packages your app depends on, you don't gain access to the newer conveniences & improvements (security, performance, etc) that have been introduced.

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

#127

Post by fouc » Sat, Jan 08, 2022, 2:41 AM UTC

partido3619463 wrote: post #74

handoflixue wrote: post #44

Earlier quoted context omitted.

Aside from being more modern than to suggest a fax, that seems to be exactly what they did?

No they refunded everyone immediately.

The sheer unprofessionalism is astonishing. They're gonna put the whole business community to shame.

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

#128

Post by asdfasgasdgasdg » Sat, Jan 08, 2022, 2:42 AM UTC

lmeyerov wrote: post #102

asdfasgasdgasdg wrote: post #29

Earlier quoted context omitted.

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.

It's the users who need to audit, the social contract of OSS is just not to be sneaky/sloppy about it (when posing as a serious project). Semvar is beautiful bc it lets you be explicit. Likewise, end users can judge "wow major version 27 in as many months, maybe not so good for us." We had a gov customer today upfront about needing slow updates, and same deal -- maybe our SaaS and OSS libs are too fast moving, so the…

I am a toil/backwards incompatibility hawk. I don't like to impose them on my customers. It's extremely rare that the balance of equities favors making a change like this, where a function that filters data and will necessarily impact correctness is changed, and not in subtle edge cases but in its primary behavior. In fact, I've never seen a case in my career where it ended up being worth it.

I'm a big fan of Linus' mantra: we don't break userspace.

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

#129

Post by fouc » Sat, Jan 08, 2022, 2:43 AM UTC

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.

You would feel spoiled if you were a ruby developer too.

This type of library API breaking change on a minor version update basically never happens.

And if it can happen in ruby land, it can happen in JS land too.

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

#130

Post by kortex » Sat, Jan 08, 2022, 2:45 AM UTC

dragonwriter wrote: post #113

kortex wrote: post #112

Earlier quoted context omitted.

That is asinine. Why not change it in 5.x->6.0 if they knew it was a problem. Why even use version numbers at that point? Just use DateVer or 0ver at that point.

> Why not change it in 5.x->6.0 if they knew it was a problem Because Rails explicitly has a versioning policy where minor versions are equivalent to SemVer major versions (but with deprecation notice in a previous minor version) and where major versions are also SemVer major with subjective significance distinctions; they call it “shifted SemVer”. https://guides.rubyonrails.org/maintenance_policy.html This is somewh…

Sure, but like, you don't have to break code on .Y changes.

Changing semantics of a query operator is something worth saving for a "big major" update, if you change it all.

Some breaking changes are really obvious and easy to catch. Others can introduce pernicious bugs which slip through tests. The change Mongoid is solidly the latter. And yeah, they say they use actual Semver.