#mic

1 messages · Page 1 of 1 (latest)

night hamletBOT
jovial sigil
#

Hi there, can you elaborate more? are there logs or request IDs that you can share so that I can help with the troubleshooting?

crystal sentinel
#

Where because I was trying to create multiple checkout sessions relatively rapidly right after the user was created

#

it would result in duplicate accounts

jovial sigil
#

Let's step back a bit, what makes you think it's a race condition?

#

And what are the duplicate accounts here? are you talking about connected accounts?

crystal sentinel
#

There would be duplicate customers in stripe. I think if you read that block which is triggered on a checkoutSession creation that I linked to above it is relatively obviously a race condition. If you just create a user and they have no stripeID (linked yet) and then you create 3 checkout sessions you could result in at least 4 stripeIDs.

See this issue as an example of another customer running into this race condition:
https://github.com/stripe/stripe-firebase-extensions/issues/395

GitHub

Bug report Extension name: [e.g. firestore-stripe-payments] Describe the bug Every time a customer creates an account within my chrome extension, then buys a subscription via Stripe Payment Links, ...

#

So the obvious way to fix this was to just wait until the stripe account was linked to the user which should happen on the creation of the user in firebase before adding a checkout session.

#

That resolved 99% (not 100%) of duplicate accounts.

#

But now there a bunch of timeouts where for some reason the block never is notified of the stripeID. However, when I look in the database they all have stripeIDs. So it is possible this is an issue with firebase...

jovial sigil
#

So it's about more about duplicate creation rather than race condition, am I right?

crystal sentinel
#

duplicate creation due to a race condition where the stripeID wasn't present before the checkout session was created.

create firebase account -> create stripe account -> link
create firebase account -> call checkout session -> create stripe account -> link

#

because createCheckoutSession creates a new stripe account even if that is already happening so both a race condition AND a duplicate account

jovial sigil
#

Let's be more specific, the account that you are talking about there is customer, not connected account right?

crystal sentinel
#

correct

#

customer records

jovial sigil
#

Great, and did you specify the customer when creating a checkout session?

crystal sentinel
#

but the issue with this and I would call this a stripe BUG is

if someone does this it can result in the customer paying but not having their status linked

#

which is what happened to us

jovial sigil
#

It'll be easier to understand if you can share with me the code you wrote

crystal sentinel
#

ok

#

i did send the currently primarily relevant portion above in the gist but i can send the rest

#

because now the primary issue is the timeout

#

but i would expect that code to never timeout

jovial sigil
#

I just want to know how you create the checkout session, especially whether you specify the custeomr.

crystal sentinel
#

ok

#

well we're using the firebase extension

#

But again I think it works 99% of the time other than the timeout keeps happening a lot. And since the firebase extension is set to create and link a stripe customer on every firebase user creation I would expect that timeout to not happen.

jovial sigil
crystal sentinel
#

yes

#

using the stripe firebase extension

#

so that was where without that await call at the top that has the timeout there were the multiple customers created because of the line I linked into the stripe firebase extension code above

jovial sigil
crystal sentinel
#

I'm not calling the API directly. I'm using the Stripe Firebase Extension.

#

It gets the stripeID from firebase

#

that was the same line I linked earlier that is the whole cause of the race condition I mentioned.

#

it is the stripe extension code. When you create a new account in firebase it creates a new stripeID and links it to firebase. AND when you try to create a checkoutSession it checks to see if that stripeID isn't linked yet and creates a new account. So if that happens multiple times simultaneously it results in one of the N stripe IDS randomly being added to firebase.

jovial sigil
crystal sentinel
#

you don't call that directly

#

that is a trigger in firebase

#

that waits for the data entry which is what you see

#

in the gist I sent

#

this code

#
  .runWith({
    minInstances: config.minCheckoutInstances,
  })
  .firestore.document(
    `/${config.customersCollectionPath}/{uid}/checkout_sessions/{id}`
  )
  .onCreate(async (snap, context) => {```
#

from there

#

in the definition is the trigger thing

#

I think this issue may be hard to solve without in depth knowledge about firebase tbh

#

¯_(ツ)_/¯

jovial sigil
#

I'm not familiar with firebase I'm afraid, but I found it strange that the createCheckoutSession function doesn't take a customer param.

About the duplicate customer, it's likely that the customer is created by the CheckoutSession depends on the customer_creation and mode param. (https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-customer_creation)

crystal sentinel
#

createCheckoutSession isn't a function

#

well it's not called directly

#

I agree that the design of that thing is wacky.

#

But createCheckoutSession is waiting for a data entry in the checkoutSessions scope

#

and checking the firebase user that is logged in

#

for the stripeID

#

that's line 162 in that file

#

Are there any escalation paths for this at all? I am having a customer facing issue. As you can see here I think the issue is relatively hard to debug async.

jovial sigil
#

I'd suggest you file a issue in the github repo first, write to Stripe support https://support.stripe.com/contact and let them about this problem. They'll escalate this.