Shoop

[opal grotto]

I have a second related question, but I'm not sure if I should create a separate thread or not. Let me know what I should do!

[young lake]

Yeah you could do it that way

And feel free to continue questions in here

[opal grotto]

Ok, awesome.

Second question:

It appears there's a race condition between the redirect back from Stripe Connect and the Webhook update arriving. So, at page load time, we can’t actually rely on the webhook information on our side to correctly determine which state we’re in.

Specifically, we wouldn’t be able to differentiate between “Clicked Save for Later” and the Limbo State of updates not having been delivered over webhook yet.

What should I do in this case?

[young lake]

Yeah that's tricky. It's up to you really. You could consider some intermediary state or some incomplete state of your application that your users can access but don't have full access until you receive the webhook

[opal grotto]

Got it. I'm considering doing something like this:

Upon the pageload redirecting back from Connect, the page blocks loading on querying Stripe directly to get the current source of truth. If we see details_submitted is false, then we know we're in the "Save for Later" state.

the reason I think we can't use an intermediary state is we have no way to confirm the absence of a webhook event, and definitively say we're in "Save for Later"

Does that seem like a reasonable implementation / avoiding the race condition?

[young lake]

yeah you can do that if you'd like

[opal grotto]

ok, thanks for the help!