I would have given up after the first failure, and used a different streaming service. I have zero patience for consumer technology that doesn't work, after spending every work day dealing with enterprise technology that doesn't work.
In the spirit of yes, and: how about a subscription similar to a pay as you go phone plan? Pay for the month, and when you don't pay, then you don't get to keep going. After a couple of months, they unsubscribe you, get rid of your account, etc. More often than not, the first thing I do when I sign up for a service is cancel it (after confirming I can use it for the billing period).
I can easily see myself failing to catch this type of bug, especially if when you run it locally, the latency on jobs from enqueue to finish is aboue 5ms, whereas it probably fluctuates in production from a few ms to 5 minutes. It probably passed QA when latency was low.
If the desire is to mostly keep this architecture, the flag in the DB for "has a streaming account linked" needs to not be a boolean, and then you could have a third state besides "Ready to link" and "Link": 'Pending unlink' which would cause the UI to ask the user to stand by until the streaming site confirms the unlinking. Mildly inconvenient for the 0.1% of people who need to unlink just to immediately re-link, but better than buggy.
Completely off topic but the title made me wonder if there’s any subscription service that cancels you if you don’t use it? Not quite usage based billing - plans that cancel (or pause) without use? I can’t think of any - terrible business model of course
In 2020 Netflix claimed they would start to automatically cancel inactive accounts [1], but the post has since disappeared. I also remember Microsoft saying the same thing about Xbox Game Pass but have not searched for their statement.
Kagi arguably “pauses” your subscription if you don’t use it in a month. They give you a credit at the end of the month that then applies to the next month, so that people aren’t charged if they aren’t using it.
I can't imagine the frame of mind the author has to be in to think that there's moral value in not "naming names" of corporations that do things badly, as if they are people who can be offended. Although they also write cringe things like "to the builders <heart emoji>" so perhaps I will just never understand them.
There’s a lot of bleeding heart people like this. They add variety to the world. The downsides being things you mention, but it’s usually more palatable than someone on the other end of the spectrum.
I think it would distract from the points he's making. The article could be misread as a rant about a bad time he had, when it's actually meant to make a specific point about considering async vs sync transactions and what happens when they're combined in the same system.
And I don't believe that only one streaming service and one bank makes such mistakes.
I don't think its for moral value but rather they want to make a general point. For example Netflix couldn't care less if they were named or not named in this blog so what purpose is there to "name and shame" them? Most normal people dont even know what a request is so its not like there is any reputation damage risk here for Netflix and the author can write without any bias and talk about general tech and its shortcomings/quirks.
That is the frame of mind and seems pretty reasonable.
> Here, purely-async makes more sense than purely-sync:
> From a user experience perspective, the user has no need to wait around until the link is severed. They expressed the intent to sever the link, and were told this would be accomplished. Generally, that's sufficient.
That's incorrect I'm afraid. The reason the flow is synchronous for linking is so that the user can consume the service as soon as they link it. Async means they would have to wait, no user wants to wait.
Similarly, cancellation is asynchronous so that the service doesn't stop immediately. This benegits both the service and the bsnk or credit card company since users often do change their minds and resume the service during the "cool-off" period.
tl;dr, the current logic is correct, it just does not work for your use-case, which is understandably frustrating.
There is a coffee shop here that has a membership plan (you can roast at the shop it’s cool. Membership = no charge to roast and discounts on beans). It’s monthly and you have to re-up to keep it. It’s great and I’m happy to support them.
If the desire is to mostly keep this architecture, the flag in the DB for "has a streaming account linked" needs to not be a boolean, and then you could have a third state besides "Ready to link" and "Link": 'Pending unlink' which would cause the UI to ask the user to stand by until the streaming site confirms the unlinking. Mildly inconvenient for the 0.1% of people who need to unlink just to immediately re-link, but better than buggy.
Kagi is one of them.
[1]: https://help.kagi.com/kagi/faq/faq.html#fair-pricing
I recall a db service does that too long ago. Although I'm not sure if they changed policy as it's been a while.
they had a whole webinar about it with all sorts of justification, although most of it sounded like mba-isms to me.
[1] https://web.archive.org/web/20200522032356/https://media.net...
And I don't believe that only one streaming service and one bank makes such mistakes.
That is the frame of mind and seems pretty reasonable.
> From a user experience perspective, the user has no need to wait around until the link is severed. They expressed the intent to sever the link, and were told this would be accomplished. Generally, that's sufficient.
That's incorrect I'm afraid. The reason the flow is synchronous for linking is so that the user can consume the service as soon as they link it. Async means they would have to wait, no user wants to wait.
Similarly, cancellation is asynchronous so that the service doesn't stop immediately. This benegits both the service and the bsnk or credit card company since users often do change their minds and resume the service during the "cool-off" period.
tl;dr, the current logic is correct, it just does not work for your use-case, which is understandably frustrating.
What's everyone's favorite torrent site these days? Mine is Bitsearch, it has absolutely everything