#jmak

1 messages · Page 1 of 1 (latest)

vague oreBOT
solar crest
#

Hi! Let me help you with this.

#

What DB are you talking about here?

proven shell
#

I have a CockroachDB that I have set up where I will mark a user as subscribed once i receive the customer.subscription.updated event

#

however, it doesn't seem to work when the checkout.session.completed and customer.subscription.updated are sent together

#

but there are no errors

#

when i resend the customer.subscription.updated event, the DB changes it correctly

#

I am wondering if this has to do with the time of these events being sent literally 1ms apart

#

but I am returning status 200 on the first request, just the DB doesn't seem to update

solar crest
#

I don't know how the logic of your application works so it's hard for me to help.
If there's a ✅ that means that your app has received the webhook event from Stripe and responded with OK.

#

Maybe you could send some code that's related to this logic?

proven shell
#

this is the code where the subscription is created. in q.CreateUserSubscription I will update the DB

#

This case comes before my checkout.session.completed

#

see here

solar crest
#

Try using logs to see where your flow stops. I don't see anything out of the ordinary in the code.

proven shell
#

ok

#

standby

#

It seems theres a null pointer in CustomerDetails

func getUserFromStripeCustomerEmail(session *stripe.CheckoutSession, c *gin.Context, q db.Queriers) (user *models.User, err error) {
var email string

if session.CustomerEmail != "" {
    email = session.CustomerEmail
} else { // get it from the customer details
    email = session.CustomerDetails.Email
}
user, err = q.GetUserByEmail(email)
if err != nil {
    c.AbortWithError(http.StatusBadRequest, err)
    return
}
return

}

#

but the customer details show that its filled in

#

is customer details not automatically part of the included fields

#

@solar crest

solar crest
#

Please, let me check

#

Please share the ID of the webhook event evt_xxx

#

You might need to expand the customer

proven shell
#

expanding now and testing

solar crest
#

Yes, I see customer is just an ID cus_xxx

proven shell
#

okay i just tried and it looks like ist still not working

#

this is with customer expanded

solar crest
proven shell
#

i fixed that one -- it looks like its coming from checkout session completed

#

im not sure if its a logging thing but that checkout session completed seems to log first..? but the times are off

solar crest
#

Please don't rely on the order of the events. Stripe does not guarantee that events are sent in any specific order

proven shell
#

even the creation times?

solar crest
#

What do you mean?

proven shell
#

do the creation times matter

solar crest
#

The creation time will be correct, but some events might arrive later than others.

proven shell
#

im just so confused what could be going wrong

#

when i resend the events independently, everything works as expected

solar crest
#

Why are you listening to both events?

proven shell
#

this is all within one big handler

#

thats why i have multiple case statements

#

otherwise i listen to checkout.session.completed because i have other independent items people can buy

solar crest
#

Okay, so where's the issue now?
You said you fixed one?

proven shell
#

the issue is that subscribed is not being set to True

solar crest
#

In your database?

proven shell
#

yes

#

it doesn't work when its sent together with checkout session completed

#

but independently it works

solar crest
#

The problem is in how your application handles it. It's a bit hard for me to debug your own code for you. It will help me if you at least point me at the place where it stops working.

proven shell
#

it doesn't stop working anywhere it just continues to flow through

#

does async_payment_succeeded get called at some point?

solar crest
#

What's async_payment_succeeded?

proven shell
#

the event

#

for payments

#

im receiving no bugs in handling any events and am handling all errors and logging

vague oreBOT
solar crest
proven shell
#

mhmmm

#

i'm not tracking that one

#

but it should be working on the events that I capture no?

solar crest
#

You don't need to listen to all events.

proven shell
#

are you aware of potential race conditions?

#

it seems like sometimes it works and sometimes it doesnt

steep delta
#

Taking over here, can you summarise the issue? Equally, as my colleague noted if you don't intend to action an event type then don't configure your webhook to listen for it.

proven shell
#

we are listening to a few events right now but the only ones that are pertinent are checkout.session.completed and customer.subscription.updated

#

when these two events are sent in tandem, sometimes the DB doesn't update for customer.subscription.updated

#

but upon resending the DB properly updates

steep delta
#

Well this is something that your integration needs to account for. We don't guarantee event ordering, and the nature of those events and your integration means that they will likely sent at the exact same time.

#

You need to debug your code and figure out why the checkout.session.completed event is reversing/preventing whatever database logic/call you're making.

proven shell
#

hmmm

#

standby

#

u may be right

#

because its taking in pointers and perhaps calling update simultaneously

steep delta
#

Yep, seems that way

#

Definitely a race condition issue, but hard to debug without full context of your code.

proven shell
#

okay

#

i fixed it

#

it was a race condition

#

thats a nasty bug

steep delta
#

Which bug?