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

331–336 of 336 posts

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

#331

Post by [deleted] »

ljm wrote: post #272
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.

'Auditing all your code' isn't the same as looking up the changes for a certain version on its github release page or a changelog page (if it has one). It's not the responsibility of OSS maintainer to ensure your software still functions after an upgrade if you're not even willing to spend a modicum of effort to hold up your own end of that bargain. This isn't a big ask, it's why there are changelogs and release note…

[deleted]

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

#333

Post by Xavdidtheshadow »

lamontcg wrote: post #329
Xavdidtheshadow wrote: post #328

Earlier quoted context omitted.

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

> We do major version bumps on a yearly cycle and people get stuck on 8 year old versions and won't upgrade

We do the same thing and have the exact same experience, unfortunately. Software is a messy business and it's hard to apply strict rules to human process.

I think ultimately SemVer can be used to to accurately communicate if you, a user, are safe to upgrade between versions if applied strictly. Whether or not your users will (or be happy about it) is another ballgame.

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

#334

Post by ilyazub »

SerpApi dev here. I've requested, reviewed, tested, and deployed this upgrade of gems.

I want to clarify some things. This code was running on staging for three weeks before the deployment to production. There were four application errors on staging that were related to the problem with subscription renewals.

I and the author of the pull request have made three mistakes:

- haven't carefully read code in all methods from the backtrace of four app errors on a staging environment

- upgraded several gems at once

- didn't review the changelog of mongoid gem

As multiple people commented here, integration tests for renewals should've been caught that bug. We hadn't a test case when all user's subscriptions are checked after the renewal of a specific test user.

So the lesson here is to not yolo minor upgrades of dependencies and avoid mistakes above.

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

#335

Post by cpursley »

Nextgrid wrote: post #286
cpursley wrote: post #200

Earlier quoted context omitted.

I guess this is a Rails thing where people treat the db as a just dumb store.

Do you have any resources you can recommend about using the DB for more than just a dumb datastore? The first thing I'd be concerned about is how do you manage changes? Code is easy to version control, deploy and roll-back. Database state and things such as triggers, stored procedures, etc, less so.

Here's one example: https://sive.rs/pg

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

#336

Post by zestyping »

flubflub wrote: post #269
zestyping wrote: post #216

Earlier quoted context omitted.

And another: 4. Don't design an API that mixes fluent style (methods are like infix operators) with conventional style (methods are like prefix operators). Fluent methods should never take multiple operands. It's a terrible, horrible, no-good, very bad idea.

I think the default should be named prefix operators. Then you can have infix operators that are aliases. This is a problem in Haskell with infix operators being directly defined I would argue. I disagree that infix and prefix should not be mixed. Although there is a special hell for people who use + with non-commutative operators.

Infix operators are fine. But _methods_ that masquerade as infix operators shouldn't mix with methods that work like prefix operators.
Post reply on HN