- 🇬🇧United Kingdom problue solutions Northern Ireland
I have re-visited this as I've had to do some work on an older project.
I have encountered this bug again while doing some testing for a seperate issue and I'm pretty sure this is caused by not handling idempotency (basically duplicate requests):
https://docs.stripe.com/api/idempotent_requests
Sometimes, but not always, the stripe event customer.subscription.updated is triggered at the same time as customer.subscription.created. This seems to happen more in the case of a wallet payment, but I have also seen it occasionally happen with a standard credit card payments, it seems in this case there is some kind of glitch where Stripe cant access the endpoint at that moment in time and then a second later sends an update event. The important point though is that the idempotency_key property for both webhook events is the same (meaning it's the same request), and this module does not check for, or handle that. This means a duplicate 'local subscription' is created.
From the documenation on the link above, there is an assumption that you already have that idempotency_key value when interacting with the API so it seems to me that it needs to be stored on the subscription entity when its initially created, so it can be checked to prevent a duplicate local subscription?
Does this make sense to the maintainers?
- 🇬🇧United Kingdom problue solutions Northern Ireland
A workaround (or fix I'm not sure) is to simply not react to the customer.subscription.created event in WebHookSubscriber and only react to customer.subscription.updated as it's always sent when the subscription is created anyway. Not sure of other implications but works in all scenarios for me.