#oleg-codaio_api

1 messages · Page 1 of 1 (latest)

lone scrollBOT
#

👋 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/1279126193030824017

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

solemn fern
#

This happens when we update a subscription from monthly to annual

#

Appears to be a regression on Stripe's end?

#

The new pending_invoice_item_interval we're setting is compatible with the updated subscription's natural subscription interval

lone scrollBOT
grizzled mauve
#

Hi 👋

#

I'm taking a look at your request now

#

Do you have an example of where this did work in the same situation?

#

I'm seeing internal error messages saying that a new invoice should not be generated because the current period has already been invoiced for

#

I agree the error message sounds confusing

solemn fern
#

Hmm

#

Let me take a look

grizzled mauve
solemn fern
#

Right, so what's going on here is we have a monthly subscription that's updating to an annual subscription, with a monthly pending invoice item interval

grizzled mauve
#

Just the ID please, I cannot use the Dashboard link

solemn fern
#

req_9IcgEAUll251yF

grizzled mauve
#

Thank you, taking a look.

#

Okay... one thing that jumps out to me here is that an Invoice was created for this request, so it wasn't at a point where the current period had been already invoiced.

#

I also see that, with the succeeding request, there was a proration_date included.

solemn fern
#

Let me take another look

#

proration_date is also included on the failing request

#

Okay... one thing that jumps out to me here is that an Invoice was created for this request, so it wasn't at a point where the current period had been already invoiced.
The successful request had the same setup though

grizzled mauve
#

Sorry, I think I have too many tabs open 😅

solemn fern
#

The current period was already invoiced, then the subscription was changed to have a different term

#

No worries!

#

In the successful request - the intial invoice came in at 3:25am, that was for a monthly subscription. Then half an hour later the customer changed to an annual subscription

#

This is also what's happening in the failing request

#

This is on our test environment - our internal QA team tests this same scenario every single night.

#

I just checked our production account in live mode - we just had a request like this go thorugh: req_MdTAXFRRxgs6lY

#

It kind of seems like a change in behavior/regression that has only been enabled on test accounts, but not rolled out to live mode just yet

grizzled mauve
#

Okay I can see some of the logic that is being executed internally and where there is a clear divergence

#

I'm going to flag this internally

solemn fern
#

Alright, thanks

grizzled mauve
#

Okay we have actually multiple users asking about this

#

Was the request you shared here the first time you noticed this error? Was the request on 8/29 successful?

solemn fern
#

Yeah, first time I noticed it

#

So like around 8 hours ago

#

We didn't see any errors the night before so must be a regression from the last day

grizzled mauve
#

We are currently investigating this

solemn fern
#

Great! At least it's only affecting our test/QA environments

grizzled mauve
#

Yeah, that's definitely good we flagged this before it hit production.