#rhmayer-hiya_preserve_cancel_date
pine joltBOT
👋 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/1474444258743419113
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
rich chasm
Hello, do you have the ID of a subscription/schedule taht you saw this behavior on?
cedar meteor
pine joltBOT
valid girder
👋 Taking over for Pompey as they have to head out. I'm looking over your example subscription now.
From looking at sub_1SxPHFGhDr1u9rxFg2X0Ff2U and it's corresponding Subscription Schedule sub_sched_1T2DQzGhDr1u9rxFVH8qSXYd I can see the Subscription Cancellation was triggered from your backend, but the Subscription Schedule release was triggered from your Dashboard with preserve_cancel_date: "true"
The request log for the Dashboard triggered Schedule release can be observed here:
https://dashboard.stripe.com/acct_1QAKacGhDr1u9rxF/test/logs/req_5U5o0o5gret7rr
Also keep in mind preserve_cancel_date is not a persistent property of a Subscription Schedule object. It only applies to the requests made with using that parameter.
Do we have another example where the schedule was released with preserve_cancel_date: "true"
I can also see that a second schedule, sub_sched_1T2DXlGhDr1u9rxF1k6Tn6Ok was created for the same Subscription after the first schedule was released from the Dashboard. That second Scheduled was released by API but the request logs show that preserve_cancel_date wasn't passed in the API call to release
https://dashboard.stripe.com/acct_1QAKacGhDr1u9rxF/test/logs/req_JJpfvVmF1H6JbR
I think the key here is ensuring preserve_cancel_date: 'false' is passed in the release call.
Should also note that preserve_cancel_date does not have a default behavior. If it's not passed, the cancel_at date will be preserved if end_behavior is cancel or none and the cancel_at will be reset if end_behavior is release or renew
So you need to explicitly pass preserve_cancel_date: 'false' if you want to decouple the preservation of cancel_at from end_behavior
valid girder
rhmayer-hiya_preserve_cancel_date