#neils_666
fluid sapphire
Hi, let me help you with this.
The key is to not in handling it technically in a certain way, but to build out the business logic to take concurrency into account.
What's your use case exactly, and I will try to suggest a solution.
fresh imp
user subscribes, we get 'subscription created', start handling it (creating db records), then whilst we're doing that - 1 millisecond later - we get 'subscription updated'. The second call will try to create or update a db record and there will then be a race to see who can commit to the db first. Sometimes they interleave such that by the end of the two operations the db record is left with status 'incomplete' but the 'subscription updated' request tried to set it to 'active'.
fluid sapphire
I recommend you to just listen to invoice.paid event, then check if the given Customer ID has a Subscription record in your database, if no, create it, if yes, renew the Subscription.
fresh imp
We're currently not handling invoice events and relying entirely on subscription events, which works well other than this race condition. Changing will be fairly significant. Are there any other options?
fluid sapphire
I don't see any other straightforward way, unfortunately.
Not all customer.subscription.updated events are related to Subscription renewals.
Maybe you could check the previous_attributes of the Event to see if the update is related to the renewal: https://stripe.com/docs/api/events/object#event_object-data-previous_attributes
But I strongly recommend to stick to invoice.paid event.
fresh imp
Thanks. I don't think it's safe to ignore any events without previous_attributes , I could imagine there are other scenarios in which we might receive two customer.subscription.updated requests in quick succession and we could have the same interleaving problem.
If an invoice.paid event is about a subscription does it include the full subscription details under the subscription key or is it null and we have to make a request to get that data?
I guess that if not relying on customer.subscription.updated events then we should also process other types of invoice.x events in case there is a chargeback or something?
fluid sapphire
It's not null if this Invoice was generated by a Subscription. You will get the Subscription ID, and you will either need to make a call to get the Subscription details, or expand the event payload.
signal voidBOT
fresh imp
Ah. OK. That's not terrible. Perhaps I can expand the subscription then send its data to our current functionality that handles subscription object updates.
fluid sapphire
👍
fresh imp
Thank you!
fluid sapphire
Happy to help.