#lec_schedule-phases

1 messages · Page 1 of 1 (latest)

vale nacelleBOT
#

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

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

humble folio
#

lec_schedule-phases

#

👋 There's no "propagation time" at all in our API so that can't be it.

What do you mean "queried the next phase" exactly? there's no API for "next phases". We return all the phases configured on your SubscriptionSchedule on creation/update so I don't really get your question

teal bane
#

I mean I queried the schedules for the customer that owns the subscription. Then I searched for the phases in the response.

humble folio
teal bane
#

there are 2 systems:
system A created the schedule
system A updated the previously created schedule and added a new phase
system B queries the schedule
system B looks for the phase in the response

humble folio
#

Okay what does "system B queries the schedule" mean in terms of exact code

teal bane
humble folio
#

Sorry don't dump the entire code.

#

Just show me the few (likely less than 10) lines of code where you "query the schedule"

teal bane
#

ok, so System B code I will send it below

#

`
SubscriptionScheduleListParams params = paramsBuilder.build();
schedulesCollection = SubscriptionSchedule.list(params);

        List<SubscriptionSchedule> retrievedSchedules = schedulesCollection.getData();

        Optional<SubscriptionSchedule> optionalSubscriptionSchedule = retrievedSchedules.stream()
            .filter(schedule -> stripeSubscriptionId.equalsIgnoreCase(schedule.getSubscription()))
            .findFirst();

        if (optionalSubscriptionSchedule.isPresent()) {
            SubscriptionSchedule schedule = optionalSubscriptionSchedule.get();
            SubscriptionSchedule.CurrentPhase currentPhase = schedule.getCurrentPhase();

            long futurePhases = schedule.getPhases().stream()
                .filter(phase -> phase.getStartDate() >= currentPhase.getEndDate())
                .count();

            return futurePhases > 0;
        }

`

#

In general, system A and B implementations work well
the error I'm describing you is rare. To be honest I have never seen it before.

humble folio
#

Why are you callin the List SubscriptionSchedules API instead of knowing the exact SubscriptionSchedule to fetch?
Is it possibe you are looking at the wrong one? Or making that call before the update?

Really I can tell you with certainty this can not be due to lag or a bug on our end.

teal bane
#

Why are you callin the List SubscriptionSchedules API instead of knowing the exact SubscriptionSchedule to fetch?
the code you have seen is system's B code. This system knows the customer ID and knows that this customer has a subscription that has a schedule, but it doesn't know the schedule ID.

Is it possibe you are looking at the wrong one?
It is impossible to look at the wrong one. By the way, this code has always worked and has retrieved the customer's schedules correctly every time.

Or making that call before the update?
considering the scenario where code from systems A and B are executed, there is no chance the query call was made before the schedule update call.

humble folio
#

Gotcha. I am certain this can't be a bug on Stripe's end. This is 100% something in your code/logic. Unfortunately we can't really say what if it's not reproducible

teal bane
#

ok

#

just out of curiosity, is there documentation that mentions how much time it takes for Stripe to propagate changes?

humble folio
#

There is no doc for this because there is absolutely no delay. Our API is synchronous. As soon as you make the Update SubscriptionSchedule call and the rerquest completes the changes are instantly reflected

teal bane
humble folio
#

That's unrelated, that's for the Search API though which is backed by a completely different system

teal bane
#

so the search API is asynchronous and all other are synchronous?

humble folio
#

yes

vale nacelleBOT