#stephen-crosby_subscription-lifecycle-cancel
flat blazeBOT
👋 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/1382486701116489810
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
naive jackal
HI 👋
I can understand the confusion here. When I look at the timeline for the related Subscription I see the invoice.payment_succeeded occurred at 2025-06-10 18:43:23 and the customer.subscription.deleted event fired at 2025-06-10 18:43:33.
young oak
Right. But the DELETE request was at 18:43:21 according to the logs
naive jackal
But that was postponed because there was an active checkout session that was mutating the objects. This is why a request 1s earlier got an error: https://dashboard.stripe.com/logs/req_v6QyvHeqaJYep9
young oak
That is interesting. Why do I not see that request here:
naive jackal
You have multiple filters applied, I would make sure you are not filtering out failed requests
young oak
I cleared those filters, but I still don't see it. How did you find it?
naive jackal
We have a section in our Admin pages for the Subscription that shows recent requests that involve this object.
It looks like you are looking at the Customer object. Try filtering on the Subscription ID instead
young oak
ok i see it. can you help me understand "that was postponed because there was an active checkout session that was mutating the objects"
if i request a subscription cancellation and there is an active cehckout session. does that mean this request is denied or truly delayed, as in stripe will do it later?
looks like the message says "You cannot cancel a subscription with an active checkout session. Expire the checkout session instead"
naive jackal
Yeah what that error message returned is basically saying the customer has created a checkout session (most likely via the hosted invoice page) and is attempting to pay this invoice. So when your request succeeded a second later, they had completed the session and made their payment.
It's definitely a race condition and not something I think there is an easy or "right" way to handle
young oak
Are you able to tell me what state this subscription was in when I deleted it?
the subscription.status
naive jackal
Sure the last two state transitions are likely the most important.
At 2025-06-10 18:43:23 the status went from incomplete to active as we completed processing the payment. At 2025-06-10 18:43:33, the status went from active to canceled
young oak
That's a drag. I issued 2 delete requests, probably because the first attempte failed at 43:20 and then 43:21
although maybe there is something i can do with this info. if the subscription is still incomplete, maybe i should not cancel it due to a failed invoice payment
naive jackal
Yeah that part is really up to your business logic and how you provision access. In this case the Sub status was incomplete until the payment went through so you could try using that status to indicate whether or not the customer should be able to utilize your service.
Maybe you could implement some outreach to the Customer after X number of failed attempts?
young oak
yes. we already skip processing incomplete subscription events when provisioning our service to customers, so I think in our case there is probably no need to cancel incomplete subscriptions when a payment fails
Please do tell me if you think that sounds like a weird choice. But I think I'm convincing myself this is the right thing to do
naive jackal
I think that makes sense. In that case you can rely on the Subscription Lifecycle to determine whether to allow customers to access you service.
young oak
Oh nice. I really love the visual here. I had not seen it
naive jackal
A decent flow diagram really helps the words make more sense
So in this case the Sub would have expired after 23 hours past the first failed payment if there was no successful payment.
young oak
Yes. Do we get a guaranteed subscription updated event for every state change no matter where they come from?
(subscription state change that is)
naive jackal
Can you elaborate on what you mean by "no matter where they come from"?
young oak
hm. that may be a bad way to phrase it. what i'm really asking is, is every customer subscription state change guaranteed to result in a customer.subscription.updated event? I believe the answer is yes
naive jackal
Yes, anything that changes the state of the subscription will trigger the customer.subscription.updated event. The only exception is the request to cancel, which triggers the customer.subscription.deleted event instead