#jump_schedule-extraphase
zinc hedgeBOT
👋 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/1463237835468312577
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
tawdry kernel
Hi there, let me take a quick look at the subscription schedule
serene hinge
I believe it has something to do with request
req_lo9BbE7osPjryZ that caused it to get in this state. We have an action we take that essentially ensures we have the proper number of plan quantities on our subscriptions. This is mostly used for a per user pricing subscriptions, but most of our plans are not that anymore. This logic essentially goes through all the phases and recreates them to ensure we have the proper quantity. For subscription like this where we charge a flat rate it should do a no-op essentially. The response we get from stripe after we update the schedule from this seems to be fine. But subsequent requests to retrive the schedule have the duplicated phase. I am suspect the behavior is tied to text clock although I have some similar but slightly different behavior when not on a test clock. But that might be an unrelated bug on our part.
eternal torrent
👋 Looking instead of @tawdry kernel give me a bit of time
jump_schedule-extraphase
Can you help me debug this a bit further by sharing the exact raw JSON you get in the API when you fetch that SubscriptionSchedule and then tell me what part is a duplicate so I can inspect it further?
serene hinge
Certainly this is the payload I got from the related request id I shared in the original post. The 1 and 2 entry with index starting at 0 of course in the phase array appear to be duplicates of each other. I can even copy the text from one of them then do a code search and my IDE says there are two instances of it in the object.
eternal torrent
The 1 and 2 entry with index starting at 0 of course in the phase array appear to be duplicates of each other.
what does that mean? Index 0 and 1 or index 1 and 2?
serene hinge
Index 1 and 2
eternal torrent
Can I ask you to update the Schedule, just set metadata or similar. I want to see the exact raw JSON in the response right now (and we don't see it on GET)
serene hinge
So just add metadata on the schedule itself not on one of the phases?
eternal torrent
yeah it's really just for me to see the exact raw JSON we return right now
ah wait you might not be able to do that since you have to resend the whole phases array. Ugh that API drives me nuts
serene hinge
Ha I have also been driven nuts dealing with schedules. It did seem to work though without setting the phases. req_EHlo6u5n2rgd7d is the request id. It did it with Stripe API version 2023-10-16 although we are now using accacia for our API. We just have not updated our default version for our account in a long time.
eternal torrent
perfect, I can clearly see the bug here. I agree with you this one makes no sense and looks like a real bug. I recommend reaching out to our support team at https://support.stripe.com/contact and mention you worked with us on Discord and we confirmed it looked like a bug and reported it to the engineering team. They can then keep you updated on what's causing this
My gut is it's a glitch and since you use a TestClock you're likely already past that time. The API returns old phases by default and those are just ignored
serene hinge
Ah you are right it is technically just past time. The test clock is exactly at the end date of the phase. It was causing a bug for us because our own exclusion for past phases was just looking if current time or unix time was greater than the end date of the phase, not greater than or equal. Although that gives me a followup question. I think there is something that the way we update schedules is causing phases to get split. The 2 index phase on that schedule is essentially apart of the same billing period as index 3. I think the reason reason index 3 got split from index 2 is that when we passed the phase array back in to the update schedule route we caused it to modify. This does make scheduled harder to reason about it. It looks like the only effective change between those two indexes other than the start and end date is the invoice_setting property. I am guessing on updates making sure that object is set to undefined when we update will resolve that issue?