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

81–90 of 336 posts

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

#81

Post by thrwn_frthr_awy »

andrewxdiamond wrote: post #76
cedricd wrote: post #17

Earlier quoted context omitted.

It's clearly a breaking change how a core feature of the library behaves. This is extremely unprofessional on the part of the maintainers. I'd completely lose trust in the gem. They knew they were making a breaking change, documented it, and didn't increment a major version number. That breaks the entire point of semver. Also, this is generating SQL ffs. Like how more nasty of a breaking change could you make in term…

All dependency changes are changes. And changes should be tested before being deployed. If you update your dependencies and ship it based on version numbers alone, you can’t blame the maintainers

> All dependency changes are changes. And changes should be tested before being deployed.

OP did not say changes should not be tested.

> If you update your dependencies and ship it based on version numbers alone, you can’t blame the maintainers

OP did not if you update your dependencies and ship it based on version numbers alone you can blame the maintainers.

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

#82

Post by unionpivo »

booleanbetrayal wrote: post #55
raman162 wrote: post #50

Serpapi definitely did the right thing here. Shame on the maintainers for introducing such a breaking change in a minor version update. I guess the takeaways are: - review change logs for any gems that are updated - have extensive test cases for anything that charges customers Hindsight is always 20/20 of course.

The should have read over changelogs. What production system just accepts changes blindly without internalizing them?

most of them in the real world.

And I mean like 98% or more. I have worked in IT for over 20 years, and you actually have to fight clients managers to get time to do it.

I work in healthcare. I wish I had problem like that, instead, I just today had to fix something that was running on unpatched ubuntu 14. I know that there are servers running unpatched log4j where people are in "talks" who will pay for "upgrade" etc.

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

#83

Post by booleanbetrayal »

cirrus3 wrote: post #65
booleanbetrayal wrote: post #54

So ultimately this is the result of someone not actually reading through the changelog notes from over a year+ of iteration? I guess you can be annoyed with a third-party's abuse of SemVer, but practically everybody abuses those conventions and any developer who is versed in dependency management should have known better than to not read over changelogs. Likewise, any reviewer should have caught this.

It is... but it is also a result of a library changing the meaning of "or". This is next-level breaking change that is beyond what I'd even call a "change".

It was fully documented and ActiveRecord has done similar things in the past. See also: https://til.hashrocket.com/posts/3zyftipjiu-rails-will-chang...

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

#84

Post by rubyist5eva »

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

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

#85

Post by loktarogar »

FanaHOVA wrote: post #69
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.…

The Ruby 1.9 hash syntax was the first red flag honestly... :P

"old" hash syntax is still necessary for things where the key isn't a symbol - which was the case for 1 of the hashes

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

#86

Post by booleanbetrayal »

booleanbetrayal wrote: post #55
raman162 wrote: post #50

Serpapi definitely did the right thing here. Shame on the maintainers for introducing such a breaking change in a minor version update. I guess the takeaways are: - review change logs for any gems that are updated - have extensive test cases for anything that charges customers Hindsight is always 20/20 of course.

The should have read over changelogs. What production system just accepts changes blindly without internalizing them?

No post body was provided.

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

#87

Post by booleanbetrayal »

asdfasgasdgasdg wrote: post #29
lmeyerov wrote: post #22

Earlier quoted context omitted.

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.

Rails changed the meaning of NOT and nobody batted an eye - https://til.hashrocket.com/posts/3zyftipjiu-rails-will-chang...

These sorts of changes do in fact happen fairly frequently and developers need to be aware that they can't blindly accept upstream dependency changes.

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

#88

Post by loktarogar »

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…

yes that's true, but the bigger the set of changes between your application and the current version of dependencies, the more likely you'll have a serious issue if you are eventually forced to upgrade

the best change is no change, the second best change is a small change

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

#89

Post by nmstoker »

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…

I agree on one hand, but on the other if you take this approach, eventually the number of changes will be enormous and the cause of any issue that crops up may be that much harder to pin point. If you keep somewhat up to date, it's smaller challenges each time.

I suppose if they'd done the update into a test environment like a regular release then it's far more likely these issues would've come out there and it wouldn't have been so stressful.

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

#90

Post by asdfasgasdgasdg »

booleanbetrayal wrote: post #87
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.

Rails changed the meaning of NOT and nobody batted an eye - https://til.hashrocket.com/posts/3zyftipjiu-rails-will-chang... These sorts of changes do in fact happen fairly frequently and developers need to be aware that they can't blindly accept upstream dependency changes.

That also is a really awful change and probably broke someone in production. Really there is no reason for the not function to take more than one argument. But if you have decided to overload the meaning to NAND, you'd better not later change it to NOR!
Post reply on HN