#gallopinggoose_unexpected

1 messages · Page 1 of 1 (latest)

void surgeBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1351648367360479352

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

swift tiger
#

Clarification: "scheduled to be cancelled on Feb 28, 2025 " as in the setting was changed for the subscription to be cancelled at the end of the billing cycle on Feb 28, not that the subscription was expected to cancel on that date

random idol
#

Hi, I'm still taking a look as it looks like you've many many changes to the subscription

swift tiger
#

Thanks, I guess the time period that can be focused on is Mar 12-13 as that was when the cancel_at_period_end value was changed

random idol
#

Why are you keep making the same reuqest to update the subscription with the same fields?

#

Are you able to reroduce this?

swift tiger
#

It was just how our system was designed. There can be changes that we post to Stripe, and we use the returned subscription object to update our database with any changes. If there are no changes, the request is still made so that we can check the returned Subscription object for any Stripe-side changes that were made (our Finance department directly makes changes in Stripe sometimes)

#

Haven't been able to reproduce it yet because we just noticed the issue today and we don't have access to test clocks

random idol
#

What do you mean you don't have access to test clocks?

swift tiger
#

Oh this is a new change right? Test clocks used to be paywalled and our pricing plan with Stripe did not give us access to them

random idol
#

I'm unsure. I do not know much about pricing

#

I was able to confirm that this is a long-running bug on our end.

swift tiger
#

Yeah I'm trying to set up a test clock now to see if I can recreate it. But just looking at the events logs, it is unexpected behaviour right?

random idol
#

In this case, the cancel_at timestamp remains unchanged, so there's not material effect on your subscription behavior. It's just the canceled_at field getting updated incorrectly on our side.

#

If you retrieve the subscription, or look at the Dashboard it whould be cancelled already

swift tiger
#

I do think it is a material effect because this subscription was renewed on Mar 17 due to this value

#

We had to be manually cancel and refund this subscription, you can see this in the logs

random idol
#

Still looking

void surgeBOT
swift tiger
#

Yes we had made the request which set the subscription's cancel_at_period_end to true and the subsequent end_at but the bug that we are talking about caused that to change to false (effectively cancelling the scheduled end)

#

If we had not manually cancelled it, the subscription would have continued

random idol
#

You made the update on 2/28 so that update should have applied to the current period which is 3/17.

swift tiger
#

But it did not because there was a renewal event on 3/17 correct?

random idol
#

Right, talking to my teammate to confirm this.

#

Just ensuring that we're on the same page now

swift tiger
#

Yes, thanks

#

The subsequent events after the renewal charge: evt_1R3gRX2k4WuoSsumub8gg7VX - was the customer being surprised at being charged for another month, and hitting our cancel subscription button again, evt_1R3hsu2k4WuoSsumgNhjVGBt - us responding to the customer's complaint and manually immediate cancelling the subscription through the Dashboard

random idol
#

My teammate is jumping on here as I need to step away. They will continue investigating the issue

swift tiger
#

No worries, thanks for your help so far

radiant charm
#

That API version was explicitly set/sent by your backend (according to my tools) so this is something that somehow happened in your app.

swift tiger
#

Omg that's gotta be it thank you!

radiant charm
#

You're very welcome! 🙂

swift tiger
#

I'll definitely be more mindful of the API version when looking at these bug reports from now on. Ideally we would've upgraded our versioning a long time ago. Thanks again, take care!

radiant charm
#

Well, this is something super weird, and worth investigating on your end - because the update before and the update after were made with the correct API version, and all three of them were made with the same Java SDK version.

swift tiger
#

Our default version is still 2013-08-13 so it makes sense, I'll take a look