#ryo-ymd_unexpected

1 messages ¡ Page 1 of 1 (latest)

knotty shadowBOT
#

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

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

balmy ledge
#

hello! Which Price id is the Base Price, and which Price id is the Advance Price?

gaunt juniper
#

hi!

What I called Advance plan: price_1MQqIOJrgt3ZD9jfHhIIns1p

What I called Base plan: price_1OHK8bJrgt3ZD9jfebvPeBW0

balmy ledge
#

thanks! give me a while to take a look

#

maybe you'll want to check why your backend sent that request?

gaunt juniper
#

Our service offers customers the option to downgrade their plan in the "next cycle"!

That request looks like a feature.

The problem is, if that feature has been fine in the past, why did it produce a funny result this time?

#

nah, also, that request is a request for a downgrade reservation from 6/1, so it doesn't seem relevant to this issue.

balmy ledge
#

it does look relevant to me - your original schedule was set to change to price_1OHK8bJrgt3ZD9jfebvPeBW0 on 5/1, which it did. Subsequently, after it already switched to price_1OHK8bJrgt3ZD9jfebvPeBW0. Your backend server made another request to use price_1MQqIOJrgt3ZD9jfHhIIns1p instead

gaunt juniper
#

I see?

Let me get this straight.

  1. as per original schedule, 5/1 started price_1OHK8bJrgt3ZD9jfebvPeBW0 -> OK
  2. immediately after the update, a call was made that price_1OHK8bJrgt3ZD9jfebvPeBW0 will start on 6/1, until then it will be `price_1MQqIOJrgt3ZD9jfHhIIns1p`` -> strange

So, if that's the case, our downgrade reservation program is most likely wrong.

#

I assume the cause of this bug is that when the plan is being updated, the current_subscription plan is referenced to the old one instead of the new one (since it has not yet been completely switched over).

If this hypothesis seems to be correct, we will work on a solution for it. Any other ideas?

balmy ledge
#

for point 2, your request is starting the current phase using the Advance plan at "1714521600", // 2024-05-01 00:00:00

    0: {
      end_date: "1717200000",
      items: {
        0: {
          price: "price_1MQqIOJrgt3ZD9jfHhIIns1p", //Advance plan
          quantity: "1",
          tax_rates: {
            0: "txr_1NupjGJrgt3ZD9jfxIHHMI7i",
          },
        },
      },
      proration_behavior: "none",
      start_date: "1714521600", // 2024-05-01 00:00:00
    },