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

#301

Post by thaumasiotes » Sat, Jan 08, 2022, 5:49 PM UTC

JimDabell wrote: post #164

thaumasiotes wrote: post #79

Earlier quoted context omitted.

> When I got my last book copyedited, fixing the location of "only" was one of the most common changes. I remember a puzzle which presented a (fairly long) sentence and asked "provide a word that can be correctly inserted at any point in this sentence". The answer was "only". (Of course the meaning would change according to where the "only" was placed, but still... you'd have a hard time inserting "experience" at eve…

In case anybody is wondering, the sentence normally given as an example of this is “She told him that she loved him”. You can put the word “only” anywhere in that sentence and each position makes the sentence mean something different.

As a technicality, while it's possible for "she only told him that she loved him" and "she told him only that she loved him" to mean different things, it's also possible for them to mean the same thing.

(And in fact, the primary meaning of the first sentence is the one identical to the meaning of the second - you can read it "she only told him that she loved him [and she didn't do anything else]", but by default you'll read it "she only told him that she loved him [and she didn't tell him anything else]".)

The reason for the ambiguity is that the verb is the head of the sentence, and so an "only" placed to scope over the verb has several different options for where the scope "really is".

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

#302

Post by asdfasgasdgasdg » Sat, Jan 08, 2022, 6:13 PM UTC

lmeyerov wrote: post #192

asdfasgasdgasdg wrote: post #128

Earlier quoted context omitted.

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

I agree - we probably err too long on avoiding breaking legacy code: we are about to do our first deprecation in years as the old protocols are getting too unconscionably insecure + costly to maintain relative to our new ones. But that's company code we get paid to be stable on. Very diff story for OSS we at most contribute to, we don't assume that's part of the social contract.

Linux is also OSS. I don't think this is an OSS/paid dichotomy. This is a good software/bad software dichotomy. Also isn't this library maintained by mongo db anyway? So the "we are doing this for free" excuse does not apply.

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

#303

Post by Railsify » Sat, Jan 08, 2022, 6:26 PM UTC

kortex wrote: post #101

Railsify wrote: post #42

Earlier quoted context omitted.

Semantic Versioning does not mean you can update without reading the changelog. Blame here remains with the developer who updated without reading the changelog.

Do you or your team review every item of every changelog of every dependency in your stack (recursively for their dependencies) for every minor update, and/or 100% coverage for all of your assumptions of how they are used? Sure it was a mistake by OP in TFA but it's an honest mistake any of us could make. And it's a really Bad Move by the Mongoid devs. It'd be a bad move in 1.2->1.3, but by 7.3? I'd just be like "whe…

Yes, I generally scan the changelog and look at the diff on github from the previous version. Not doing so is penny wise and pound foolish, the risk to brand and the risk of downtime is too great to install a crypto miner, or a vulnerable log4j version, etc.

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

#304

Post by Railsify » Sat, Jan 08, 2022, 6:29 PM UTC

ljm wrote: post #251

kortex wrote: post #101

Earlier quoted context omitted.

Do you or your team review every item of every changelog of every dependency in your stack (recursively for their dependencies) for every minor update, and/or 100% coverage for all of your assumptions of how they are used? Sure it was a mistake by OP in TFA but it's an honest mistake any of us could make. And it's a really Bad Move by the Mongoid devs. It'd be a bad move in 1.2->1.3, but by 7.3? I'd just be like "whe…

I think you're trying to make the case sound a bit more absurd than it really is, in terms of recursively scanning dependencies and checking for 100% coverage for all assumptions. It's really just as simple as going to the release notes and seeing if there's a mention of breaking changes or deprecations. If no such thing is mentioned then you're fine, otherwise you go and see if that change affects you at all and jus…

This is well stated. It's about taking your fair share of responsibility, as engineering we bend code to our will, this includes reading the code of opensource packages.

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

#305

Post by lmeyerov » Sat, Jan 08, 2022, 6:49 PM UTC

asdfasgasdgasdg wrote: post #302

lmeyerov wrote: post #192

Earlier quoted context omitted.

I agree - we probably err too long on avoiding breaking legacy code: we are about to do our first deprecation in years as the old protocols are getting too unconscionably insecure + costly to maintain relative to our new ones. But that's company code we get paid to be stable on. Very diff story for OSS we at most contribute to, we don't assume that's part of the social contract.

Linux is also OSS. I don't think this is an OSS/paid dichotomy. This is a good software/bad software dichotomy. Also isn't this library maintained by mongo db anyway? So the "we are doing this for free" excuse does not apply.

Agreed in part, I'd indeed want careful motivation and change management of such a change from my language or DB vendor -- JS/Python takes years for tinier semantic changes :)

The average OSS project is just ~1 fulltime maintainer, maybe 2, with tiny drive-by contributors: there are great studies measuring this. Even most popular and long-lived OSS projects are more like that than Linux. The exceptions are inspiring, but most (my bet, I don't recall stats here) seem to be open core largely driven by 1 company. Something foundational with many contributors under open governance like Linux is better to discuss as an abnormality ("why can't the typical project grow to this size, maturity, tooling, and stability?").

So when talking about modern OSS, the typical case of looking through a pip or npm tree is NOT big shops and instead something closer to a network of volunteer passion project. From such individuals, I'm thankful for semvar, CHANGELOG, CI, and a few niceties like that. From there, the history of BREAKING would signal the project moves too fast for us or with too big swings, or looks more acceptable.

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

#306

Post by kingcharles » Sat, Jan 08, 2022, 7:01 PM UTC

emodendroket wrote: post #185

kingcharles wrote: post #106

Earlier quoted context omitted.

Actually had this recently when helping out a friend who was targeted by a shady debt collection company. The only way their lawyer would speak to us is through fax, in order to try to act as a barrier to anyone actually trying to dispute their bullshit.

When I moved out of Massachusetts I had to send a few faxes to state agencies! Well, it's not too painful with Hellofax I guess.

Yeah, thank god for free online fax gateways.

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

#307

Post by stouset » Sat, Jan 08, 2022, 7:22 PM UTC

jchw wrote: post #211

stouset wrote: post #194

Earlier quoted context omitted.

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

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 godsend for catching accidental breaks...

Ruby is a strongly typed language.

You probably mean static types, but even that wouldn't have helped here. This was a behavioral change and did not affect any of the (implicit, in Ruby) type signatures of the function. It would not have affected any of the explicit type signatures of the function in other languages. I say this as an enormous proponent of Rust and static typing.

You are tilting at windmills.

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

#308

Post by emodendroket » Sat, Jan 08, 2022, 7:47 PM UTC

blindmute wrote: post #299

newaccount74 wrote: post #259

Earlier quoted context omitted.

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.

I'd say that updating any version of anything, without reading the changelog, is irresponsible. Why are you updating a gem if you have no idea what has changed?

In other programming environments people do this without issue routinely.

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

#309

Post by emodendroket » Sat, Jan 08, 2022, 7:49 PM UTC

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…

But it's not really about a single maintainer and project, is it? The thing is that this sort of problem is somewhat common in this environment, which is why people have adopted "rules" they consider common sense about which hoops you're supposed to jump through before minor version updates.

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

#310

Post by emodendroket » Sat, Jan 08, 2022, 7:54 PM UTC

Gigachad wrote: post #217

gedy wrote: post #203

Earlier quoted context omitted.

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

That’s often the case but for this particular issue, it could have happened in any language because it’s still returning the exact same type. Its an array of the same record type in both instances.

Ultimately this is more social than technical.