#driesvints

1 messages · Page 1 of 1 (latest)

still rampartBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

real zinc
#

Hi 👋 sounds like you were working with one of my teammates earlier who is not online right now. Can you summarize the concern that you had raised to them?

safe rampart
#

I'm not sure why these get closed? Isn't it easier to keep everything in a single thread?

#

Now I have to explain all over again :-/

real zinc
#

We close threads because we rotate who is staffing the server at any given time, if a thread goes dormant it isn't worth handing over the context about it to the next person if the thread isn't going to go active again while they're around, so it's closed. It's usually easiest if you're able to work synchronously with us when you reach out, but we understaand sometimes meetings or other work gets in the way of that.

safe rampart
#

Yeah I totally get that. I'm used to getting support from Stripe in our shared slack channel where we just continue on the thread which makes it easier for everyone to follow along and stay on the same page so we're not discussing stuff in one single slack channel. I had to move here because that channel became dormant so still getting used to the flow here.

#

I still feel a single convo is easier to keep up with (like a support ticket) but I get that you are using a flow that works for you

#

anyway... we had an issue where a subscription item was replaced with a new one but with the same price id instead of Stripe just updating the original proce. @fast cypress found out the request for it: req_NDonJSuA5dBUuo

This was the event causing the issue: evt_1NvNfu2niB1UWjcEdtJmI73j

What happened is that we have a unique constraint on our subscription id and price id so there's never a subscription item with the same subscription id and price id. But when the event came in it tried to add the new item which was against the constraint so it failed over. We now did a change which checks for subscription item id's instead which is a safer way of doing it so we won't get that issue again.

But what I want to found out now to see if I fully understand things is why Stripe added a new item instead of updating the old one. The request that @fast cypress dug up seems to hint we did that ourselves. What I want to know is which price ID si_NYoVUySNx4ANfB had when it got deleted in req_NDonJSuA5dBUuo

real zinc
#

Gotcha, ah, and that Event is outside of retention also.

This looks like the last request where that Subscription Item hadn't been deleted, so I believe the logs for that will still show you the ID of the Price that was being used at that point:
https://dashboard.stripe.com/logs/req_qZt6cAjmfmJJAA

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

still rampartBOT
safe rampart
#

Gotcha. Yeah it does. It has a different price

#

it's weird for sure.

#

I guess we're going to let this one be for what it is. normally things should be handled properly now

#

but I do wonder why that went wrong there

#

thanks for your help