Duplicate subscriptions and no try/catch for unique Stripe ID

[MattRogowski]

Cashier Stripe Version

15.3.2

Laravel Version

10.48.12

PHP Version

8.2

Database Driver & Version

10.11.7-MariaDB-1:10.11.7+maria~ubu2204

Description

This is a continuation of closed tickets #1734 #1678 #1307 and probably others.

As several people have stated in the comments on these tickets the duplicate subscription error is definitely a problem - we have had 20+ in the last few days. I'm actually surprised the webhook is so fast that it is received before Cashier creates the subscription in the database, but I concur with other users reporting this that it does indeed happen.

I believe a potential cause of this is the index was added in this commit 3 and a half years ago, but the upgrade guide doesn't make any mention of this, which is likely why some users do not have this index (myself included). Manually adding the index also introduces the issue of having to clear our the duplicate rows.

The second issue is that the webhook doesn't wrap the insert queries in a try/catch block, meaning if the index does exist it will throw a database exception. Stripe will receive a 500 error response and will re-try it - the second attempt will work as either the query in the webhook handler or the create subscription function will find the existing subscription, however if Stripe receives too many non-2xx response codes it can disable the webhook, which is not desirable and should be avoided.

In summary, as well as the upgrade guide making a note to add this index, the webhook should suppress any exceptions regarding uniqueness to prevent Stripe disabling the webhook due to high error rates.

Steps To Reproduce

As others mentioned this issue does not always occur, but if the timing is right, you will either end up with two subscriptions or a database exception.

[driesvints]

Thanks @MattRogowski. Finally a good analysis about the issue 😅

The index is correct because there should never be two subscription records with the same stripe ID.

Can you send in a PR for both the upgrade guide as well as that try/catch approach? I'll have a look at it then.

[github-actions]

Thank you for reporting this issue!

As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub.

If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team.

Thank you!

[clementmas]

FYI, I pulled the current master-dev branch into my production app to test the PR #1761 and I'm still seeing many duplicate subscriptions created at the exact same time. One is "incomplete" and the other one active.

What's the logic behind the creation of subscriptions in both customer.subscription.created and customer.subscription.updated event listeners?

I remember seeing a sleep() workaround. It's not pretty but it would be better than the current duplication problem.

[driesvints]

@clementmas I'd recommend setting the unique constraint on the table like it's set now: 2fc1963

[clementmas]

I added the unique index but now it's filling up my error logs. So the problem persists.

What's the logic behind the creation of subscriptions in both customer.subscription.created and customer.subscription.updated event listeners?
Knowing that the events can arrive at the exact same time, it's bound to create issues. Especially without any try/catch.

[kyranb]

@clementmas

If you mean the logic as in the code itself, that's here:

cashier-stripe/src/Http/Controllers/WebhookController.php

Line 66 in 6a324ac

protected function handleCustomerSubscriptionCreated(array $payload)

Otherwise, if you're referring to why this exists in the webhook handler in the first place. Those event listeners handle the syncing of the local subscription state in your app
s database with any other events that trigger a subsription creation/update outside of your laravel app/cashier integration.

This could be in the Stripe dashboard, a payment link, a hosted checkout page, or a third party app that integrates with Stripe etc.

[clementmas]

I mean the customer.subscription.updated event should just update the subscription and not create it. Otherwise it can be created twice when that event arrives at the same time as the customer.subscription.created webhook.

When customer.subscription.updated arrives before customer.subscription.created and no matching subscription exists, a sleep is actually a decent solution because we know the customer.subscription.created event is coming. If not, then we can throw an error.

Right now I'm getting unique constraint errors every day. So either we catch that DB error specifically and ignore it or we sleep. What do you think?

[mrwhite-hu]

I am also suffering from this error, almost 99% of the time...

[RyanPaiva56]

I'm also getting this error. Our logs show:

SQLSTATE[23505]: Unique violation: 7 ERROR: duplicate key value violates unique constraint "subscriptions_stripe_id_unique" DETAIL: Key (stripe_id)=(sub_1RlcFQEJawWhFZGbdgnpvzTF) already exists. (Connection: pgsql, SQL: insert into "subscriptions" ("type", "stripe_id", "stripe_status", "stripe_price", "quantity", "trial_ends_at", "ends_at", "user_id", "updated_at", "created_at") values (provider_2493, sub_1RlcFQEJawWhFZGbdgnpvzTF, incomplete, price_1RWoOXEJawWhFZGbGvnckfvn, 1, ?, ?, 5123, 2025-07-16 20:48:25, 2025-07-16 20:48:25) returning "id")

It appears to happen when the status is "incomplete"

[mrwhite-hu]

What was the sleep solution for this problem? I really want to use it.

[TWithers]

I mean the customer.subscription.updated event should just update the subscription and not create it. Otherwise it can be created twice when that event arrives at the same time as the customer.subscription.created webhook.

When customer.subscription.updated arrives before customer.subscription.created and no matching subscription exists, a sleep is actually a decent solution because we know the customer.subscription.created event is coming. If not, then we can throw an error.

Right now I'm getting unique constraint errors every day. So either we catch that DB error specifically and ignore it or we sleep. What do you think?

@clementmas The reason for this is that Stripe doesn't send the webhooks in order 100% of the time. 99% of the time it does, but 1% of the time it will send the customer.subscription.updated before sending the customer.subscription.created. See https://docs.stripe.com/webhooks#event-ordering

That is the reason behind both methods handling creation.

There is still a problem though with race conditions, which I think we have run into again, which is why I am here looking at this thread. Here is what I think is happening:

• handleCustomerSubscriptionCreated() with status: incomplete -> Query to find subscription -> no subscription found
• Simultaneously, handleCustomerSubscriptionUpdated() with status: active -> firstOrNew -> no subscription found
• handleCustomerSubscriptionUpdated() saves the new subscription with status: active
• handleCustomerSubscriptionCreated() calls updateOrCreate and updates the subscription back to status: incomplete

@mrwhite-hu
The solution is to leverage the WebhookReceived event. Create a listener that checks the payload to see if it is a customer.subscription.updated event, and then sleep(5);. As long as your listener is not queued, it will happen prior to the handleCustomerSubscriptionUpdated method call in Cashier.

Ideally, a better solution would be to leverage some sort of atomic locking per subscription id to prevent race conditions and duplicate key errors. Using MySQL's built in locking, you could do DB::select('select GET_LOCK("'.$data['id'].'", 5); to acquire the lock as soon as the message arrives, and then DB::select('select RELEASE_LOCK("'.$data['id'].'")') to release it after handling it. Not sure about widespread SQL support though. Could possibly leverage lockForUpdate(), but haven't used it enough to know for sure if it would work or not.