#azuken_code

1 messages · Page 1 of 1 (latest)

fiery basinBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1468928386150694922

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

safe wedge
#

Here is my function :

async initStripeCheckout(clientSecret: string, fromInApp = false, refresh = false): Promise<StripeCheckout | null> {
      if (!this.stripeCheckout || refresh) {
        if (!this.stripeClient) await this.initStripeClient();

        if (this.stripeClient) {
          console.debug('Initializing Stripe checkout...');

[...]

          this.stripeCheckout = this.stripeClient.initCheckout({
            adaptivePricing: {
              allowed: this.isAdaptivePricing,
            },
            clientSecret,
            elementsOptions,
          });

          this.stripeCheckout.on('change', (checkoutSession) => (this.checkoutSession = checkoutSession));

          const loadActionsResult = await this.stripeCheckout.loadActions();
          if (loadActionsResult.type === 'success') {
            this.checkoutActions = loadActionsResult.actions;
            this.checkoutSession = this.checkoutActions.getSession();

            console.debug('Stripe checkout initialized.');
          } else {
            console.error('Failed to load Stripe checkout actions', loadActionsResult);
            const cartStore = useCartStore();

            console.debug('Trying to recreate checkout session...');
            await cartStore.createCheckoutSession(fromInApp);
          }
        }
      }

      return this.stripeCheckout;
    },

And createCheckoutSession can call this init function, to reload UI components, but if an error occurs again, it's the begining of the loop

atomic silo
#

hey there 👋 taking a look into this

safe wedge
#

I'll try to find it

#

It's not an API call made by me, it's when I load action from stripe checkout instance

#

I do not see it in logs

#

I try to find it in devtools

#

req_rMmIV6sfROnSRt

#

I have it

atomic silo
#

ah nice, thanks for this!

#

reviewing your flow though, there isn't really a recommended way to automatically handle this situation in the way you described (i.e. identifying the reason for the error, fixing the issue, and retrying)

we don't document error types for loadActions, and while the code=null isn't really helpful, overall we don't recommend trying to automate the process of fixing the issue and recreating the session like this

#

instead, for errors like this, the recommended approach is to get ahead of them through testing and fixing your integration

for instance, the issue here is an API key mismatch, so the recommendation would be to ensure that your code uses the right credentials in the right places to avoid this error happening in the first place

safe wedge
#

Yes, for this use case we don't want to manage it, but show an error to user, and manage integration issues with other ways

#

But I have at least one case when I must handle CS creation on failure, it's when it's expired

#

Because we are associating a CS to a user cart when he creates it, and recreate it when user update it. As CS can expire, and user can leave its cart and go back 24h later, we must manage this case (we have done a migration from payment intents to CS to access to adaptive pricing features)

#

(if there is other cases when a load actions is failing, I'll be happy to know)

atomic silo
#

Ok I see. Are you looking for a specific flag in the response that indicates when you should not retry the failed request, or something else?

fiery basinBOT
safe wedge
#

A flag or a code, to put a condition before trying to recreate session

limpid moon
#

I'm curious how the 404 error in req_rMmIV6sfROnSRt can be remediated by recreating the session? This is entirely an integration issue – you're trying to init the session with the keys of a different account

#

But no, what you want is not supported today. It's valid feedback and I'll share it with the product team

safe wedge
#

I think I didn't explain correctly

#

I cannot remediate this error, indeed if there is a misconfiguration I cannot recreate a proper session

limpid moon
#

You can, you init the session using the correct key. It's not a terminal error

safe wedge
#

So I want to know that if it's this case, I don't call my create API. But if it's an expiration error, then I want to manage an automatic creation

limpid moon
safe wedge
fiery basinBOT
safe wedge
#

I did this code to manage expiration of a checkout session. But we had this infinite loop case with the misconfiguration, so in this case, I must not try to recreate session (and fix the configuration after, for example, a user is reaching us with an error message)

#

I just want to know what are the possible values of code property in error case, then do my condition to run or not my create checkout session

limpid moon
#

Are you using short-lived sessions or something? Why not just persist the expires_at timestamp?

safe wedge
#

I do not persist any session data to avoid managing extra updates in our data, I just have the ID. I have the checkout session data only after loading actions, so I cannot have this timestamp before error occurs

limpid moon
#

Yeah I mean the code values aren't documented so we won't be sharing them. I suggest designing an alternative solution that isn't reliant on them

safe wedge
#

Ok, so how can I manage to have this session expiration from front before loading actions, or even init checkout ?

limpid moon
#

(I just checked the source and code is always null – so something we'd need to improve)

safe wedge
#

Understood, because parsing your error message isn't a clean solution too

livid steeple