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

131–140 of 336 posts

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

#131

Post by ineedasername »

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…

Where I work, the biggest enterprise system we have (ERP) has has a support cycle of ToS upgrades quarterly, with only urgent security patches in-between. And detailed advisories ahead of time on which (depending on modules and features in use) must be updated, may be updated, or can be ignored.

It makes maintenance a highly predictable endeavor:

Update T+0 == dev instance

Update T+1 week == test instance

Update T+2 weeks == prod deployment.

UAT inserted as needed when there are user-facing changes.

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

#132

Post by fshbbdssbbgdd »

warpech wrote: post #7
warpech wrote: post #6

Mongoid docs[1] seem to be pretty cool about this change: "As of Mongoid 7.1, logical operators (and, or, nor and not) have been changed to have the the same semantics as those of ActiveRecord. To obtain the semantics of or as it behaved in Mongoid 7.0 and earlier, use any_of which is described below." Is it just me or is this one of the most terrible breaking changes in a popular, official library ever? [1] https://…

The SerpAPI blog author seems cool about it, too. After such a problem, I would roll back and never ever update this dependency again.

Maybe I’m just projecting, but to me the author seems deeply bothered and holding it together to write the most effective takedown of the gem’s developers.

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

#133

Post by montblanc »

kinduff wrote: post #77
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.

Learned this the hard way. No matter the change or version, I always try to double check both CHANGELOG and the commits.

I think tests should have caught that one but I agree.

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

#134

Post by henry700 »

montblanc wrote: post #133
kinduff wrote: post #77

Earlier quoted context omitted.

Learned this the hard way. No matter the change or version, I always try to double check both CHANGELOG and the commits.

I think tests should have caught that one but I agree.

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.

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

#135

Post by contravariant »

warpech wrote: post #6

Mongoid docs[1] seem to be pretty cool about this change: "As of Mongoid 7.1, logical operators (and, or, nor and not) have been changed to have the the same semantics as those of ActiveRecord. To obtain the semantics of or as it behaved in Mongoid 7.0 and earlier, use any_of which is described below." Is it just me or is this one of the most terrible breaking changes in a popular, official library ever? [1] https://…

Yeah we just changed the meaning of 'or', no biggie.

That said I would normally read 'User.where({id: id}).or({condition1},{condition2})' as 'User where id=id or condition1 or condition2' and not 'User where id=id and (condition1 or condition2)'. Though I could probably get used to either, after all you've also got languages like Lisp where 'or' isn't an infix operator either.

And doing something with any one of the results when you only expect one result to exist is just bad practice.

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

#136

Post by jahewson »

MBCook wrote: post #66
avianlyric wrote: post #56

Earlier quoted context omitted.

They don’t need to keep anything. The card details will be stored with Stripe, if they don’t actively tell Stripe to delete those details then they’ll be able to create a new subscription and charge the card. For the vast majority of cases all you need to charge a card is the 16 digit number on the front and an expiry date. Pretty much everything else is optional (CVV, Name, Address etc), but opens you up to stupid l…

Agreed. I’d go as far as to say they were irresponsible to not tell Stripe to delete/deauthorize the tokens. In fact, why does any customer in their database have ANY connection to Stripe after they’ve canceled? I haven’t used stripe but I’m guessing there’s some sort of customer ID/token. If they’ve canceled why are you retaining that? So that’s two things. Even if the code encountered a bug like they did here, it s…

Stripe offers a billing product that serves as a source of truth for the entire subscription lifecycle. Companies are legally required to maintain financial accounts and nowadays accountants can even do your reporting using the data directly from stripe.

What’s happening here is that there’s a user who has a card on file and a cancelled subscription, and an erroneous new subscription is being created under that user.

Whether or not it makes sense to remove the card from the user account depends on whether or not that user could meaningfully have multiple subscriptions or expect to renew in the medium-term future.

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

#137

Post by Sebb767 »

contravariant wrote: post #135
warpech wrote: post #6

Mongoid docs[1] seem to be pretty cool about this change: "As of Mongoid 7.1, logical operators (and, or, nor and not) have been changed to have the the same semantics as those of ActiveRecord. To obtain the semantics of or as it behaved in Mongoid 7.0 and earlier, use any_of which is described below." Is it just me or is this one of the most terrible breaking changes in a popular, official library ever? [1] https://…

Yeah we just changed the meaning of 'or', no biggie. That said I would normally read 'User.where({id: id}).or({condition1},{condition2})' as 'User where id=id or condition1 or condition2' and not 'User where id=id and (condition1 or condition2)'. Though I could probably get used to either, after all you've also got languages like Lisp where 'or' isn't an infix operator either. And doing something with any one of the…

> That said I would normally read '[...]' as '[...]'

The problem is, once you deploy to production you have (hopefully) tested this case and rely on the actual implementation.

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

#139

Post by tshaddox »

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…

When you say “breaking” in that comment are you talking about backwards compatible API changes, or straight up bugs? It kinda sounds like you’re talking about the latter, which of course isn’t within the scope of semver.

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

#140

Post by dragonwriter »

kortex wrote: post #130
dragonwriter wrote: post #113

Earlier quoted context omitted.

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

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

Arguably, it was so important that they did a big major update just to deprecate it.

Post reply on HN