#borys
native birch
wheat sorrel
let's continue here
can you paste the request IDs
I imagine your request in java is doing something (slightly) different from node
the libraries themselves just make the API requests really, so identical requests should result in identical results
dry basin
so after successfully doing update to subscription schedule via node, i implemented same via java
but request fails req_TFAeguPvRRYE33
and after request failed, i checked the schedule entity and it was changed, instead of 3 phases it has 4 now
SubscriptionScheduleUpdateParams.Builder paramsBuilder = SubscriptionScheduleUpdateParams.builder();
Integer count = 0;
for (Phase phase : subscriptionSchedule.getPhases()) {
logger.info("updating phase {}, {}", count++, new DateTime(phase.getEndDate() * 1000));
SubscriptionScheduleUpdateParams.Phase.Builder phaseBuilder = SubscriptionScheduleUpdateParams.Phase.builder()
.setStartDate(phase.getStartDate())
.setEndDate(phase.getEndDate());
for (PhaseItem item : phase.getItems()) {
SubscriptionScheduleUpdateParams.Phase.Item.Builder itemBuilder = SubscriptionScheduleUpdateParams.Phase.Item.builder()
.setPrice(item.getPrice());
DateTime endDate = new DateTime(phase.getEndDate() * 1000);
if (DateTime.now().isBefore(endDate)) {
itemBuilder.setQuantity(quantity);
}
else {
logger.info("phase ended, do not set quantity");
}
phaseBuilder.addItem(itemBuilder.build());
}
paramsBuilder.addPhase(phaseBuilder.build());
}
return subscriptionSchedule.update(paramsBuilder.build());
and this is similar request from node code
req_MCNprRjIfYJAfc
in case it will be helpful
wheat sorrel
checking one sec
yeah your two requests are different
look them up in your Stripe Dashboard Logs page
they are passing different parameters in the request body
so some mistake in your code where you are passing price_1, qty 2 price_2, qty 2
and in the other, you're passing price_5, qty 4
as the second phase
ah sorry
misread that
your first request failed, I didn't see that, one sec
you're trying to update something in the past in that failing request, no?
dry basin
the idea is to update schedule to reflect a new quantity number (so when time comes subscription gets updated to correct quantity that might have changed after schedule was created but wasn't applied yet)
seems like to update the schedule, i need to provide all phases in a same order otherwise it throws error, start_date and end_date are required, and items is required too, but i cannot update old one, so i provide items with only price id for old one
now i think of it, it would make more sense to not include ended phase during the update
fluid escarp
You can not update a phase that has already ended. Trying to update phase 1.
Ah, I initially thought you would get an error like that for passing back a phrase that had already ended. If you exclude phases that have already ended that error should go away.
dry basin
let me check, need 5 min
i think it was failing but don't have req id for that
yea it fails if i only include phases that non ended req_xvjvZPd0GEC8Rt (did this request on a different schedule entity)
but i did same via nodejs code (not including phase that ended) and it was succesfull req_a361zZWFwqYzAH (schedule entity is different again)
fluid escarp
Interesting. I am not sure why that error happened there. Your first end date is two months in the future and the phase did already start.
Looking in to this further...
dry basin
oh maybe the api versions are different, cuz java is our backend prod code, and nodejs is smth i test with
fluid escarp
Good catch, they are using different API versions. Not sure if that is the difference but I am checking in to that
dry basin
tried nodejs with the same version as java req_ZFfQwcKyIt6i3y succeeeds (java still fails with either all phases, or only active phases)
fluid escarp
Interesting. I am not having luck pinning this down at the moment and will ask a colleague. I will get back to you with what we can find.
dry basin
great thank you
fluid escarp
Can you try running this again with your java code? It looks like the error from req_xvjvZPd0GEC8Rt might have been an edge case where the subscription's first phase was ending exactly as you made that call
dry basin
trying it now
fluid escarp
Also to be clear, was making that call just as the phase was ending intentional or was that just a coincidence here?
dry basin
oh so your comment made me think, i do subscription update first and then do schedule update right after, maybe that is the reason it fails, let me try to change the order and do schedule update first
btw, tried again req_nV5Y5GwXEgywyV still fails, but maybe because of the order issue
fluid escarp
Ah, gotcha. What is the update you are doing directly to the subscription before this call?
dry basin
changing quantity on the subscription item
fluid escarp
Ah gotcha, and the schedule already exists on this subscription by that point right?
If so, it would probably be simpler to just update the schedule without updating the subscription first. That should result in the quantity being properly updated on the subscription
To be clear, I think your second call should still work regardless, so I am filing a bug report to address that edgecase. But when working with schedule, updating the schedule directly is usually the reccommended path