#bwurtz999

1 messages · Page 1 of 1 (latest)

cunning meteorBOT
strong shoal
#

Hi there 👋 I'm not sure how much guidance I'll be able to offer here. It looks like you're leveraging Laravel Cashier, which is a third-party provided Stripe-integration. So we aren't too familiar with how it is expected to work or how to configure it. You may need to reach out to Laravel for guidance if that's correct.

The error being returned by Stripe in the request you shared, indicates that the reader you were trying to interact with was busy with another request.

Is there a specific question that you had about this?

pulsar lava
#

I guess I'm not sure where to begin. But I have this happen at multiple locations (but not all locations)

#

I get time periods where requests cannot be completed

#

How do you know that I'm using Cashier?

# 
try {
            if (count($request['cartItems']) == 0) {
                // clear the reader screen
                $stripe->terminal->readers->cancelAction(
                    $cafeLocation->terminal_reader_id,
                    [], [
                        'stripe_account' => $cafe->stripe_act,
                ]);

                return true;
            }
        }
#

This is the relevant code returning the error in this specific case

#

I don't think think there is anything specific to Laravel in this

#

And when it fails I catch the exception and record it

#

I had 60 failures in a 56 second window earlier today

strong shoal
#

The user-agent included on that request matches Laravel Cashier's user-agent.

The code there does look like it matches our syntax though.

pulsar lava
#

I guess I'm kind of stuck. I don't know why this happens. And I don't know why it only effects certain locations but not others

#

Sometimes these periods of reader is busy will last several minutes

#

and the entire system is stuck and unusable when it happens

strong shoal
#

I think starting by trying to understand the pattern here is going to be key. Like does this happen randomly, or is it only encountered after a specific other part of your flow runs?

pulsar lava
#

I've recorded it in all steps of the process. Clearing the reader. Adding an item. Preparing to process a payment

steel vault
#

👋

#

can you share the reader serial number?

#

Is it WSC513124052010?

pulsar lava
#

WSC513124052010

#

yes

#

this isn't the only reader that has had this happen though

steel vault
pulsar lava
#

Yes. But then there are requests that get sent after a greater period of time. Basically, I guess I'm trying to understand why the reader was busy for a full minute

#

and if there's anything I can do about that

steel vault
#

I believe you can poll the reader object for its status

pulsar lava
#

How?

steel vault
#

the action should specify the operation its currently processing

pulsar lava
#

Ok... that should be helpful with cutting down the unnecessary requests. But... that doesn't solve the underlying problem. The reader was stuck for a full minute

#

That's a long time with a line of customers waiting. Any indication on why this is happening in the first place?

steel vault
#

it could be a network blip of some sort. Do you have the exact timeline of when it happened?

pulsar lava
#

I have the record of failed requests

#

does that work?

steel vault
#

What were the first and last requests

#

Maybe I can use that as window

pulsar lava
#

First request to fail: req_zUe1d5fl2hlqAU

#

Last request to fail: req_Se0Q6EQwDL0XzM

#

Start time: 2023-11-20 16:50:16

#

End time: 2023-11-20 16:51:12

#

UTC*

#

58 of the 60 requests were trying to clear the reader (someone was trying to start over because it was frozen). The other 2 of the 60 were attempts to set the reader to accept payment

steel vault
#

Were all affected readers connected to the same network? Or were they at the same location?

pulsar lava
#

Different locations. Different networks

#

Same behavior

#

I only added this specific error logging recently but I believe this has been happening for a while now

steel vault
#

I'm not seeing any outages or any other reports of similar behavior from users on our end so that makes it quite tricky.

pulsar lava
#

Yeah I know this is a tough one

#

I appreciate you looking

#

It's driving me crazy

#

I can't figure out what's going on

#

And I don't want to start throttling requests

#

Because when it's working properly there's no need and it will slow down checkout

#

Is it best practice to poll the reader before trying a new request?

#

Should I start throttling requests if one returns an error?

steel vault
pulsar lava
#

And there's no way around that timeout? I know as I type that it's a silly question... I'm just kind of desperate here

#

for context, here is the count of failed requests from just today, by location

Screenshot_2023-11-20_at_2.46.01_PM.png
cunning meteorBOT
steel vault
#

I'm looking into the logs on our end but not finding much

The timeline I could stitch together shows that the reader was prompting to collect payment method details at the time after SDK called processPayment, which did succeed
https://dashboard.stripe.com/events/evt_1OEafoHw0TZh88ZmaNfyRljL

After this point though, there were multiple cancel action requests which all received 400 response with reader being busy as it was shown processing the payment

pulsar lava
#

But the payment succeeded, right?

steel vault
#

almost as if the person operating the POS spammed the cancel button 😅

#

yes

pulsar lava
#

But the first clear request would be legit

#

(pressing new order resets the reader for each new order)

#

Can you tell me if any requests succeeded in the timeframe that I gave you earlier?

steel vault
pulsar lava
#

I see that time as 11/20/23, 11:50:12 AM

#

my first failed request as 4 seconds later

#

So I think that payment was actually the last thing to succeed before this all started

steel vault
#

yup

pulsar lava
#

But so was anything successful between 11:50:16 and 11:51:12?

#

And why would the request at 11:50:16 say the reader was busy? It had just successfully completed a payment

#

It shouldn't have been doing anything, right?

#

Can you see what request caused req_zUe1d5fl2hlqAU to fail?

#

i.e.: what was it busy doing at that time

steel vault
#

Looking but it'll take more time, I've escalated internally and waiting on their response.

pulsar lava
#

Ok thank you!

#

The last two requests I see before the first failure are req_1Rb36hvTFn2mkx and req_5bdm3S2bSzRoV6, both of which succeeded

#

So yeah it would be really helpful to know what it was working on that caused the error

#

I have to drop but can you please post what the reader was working on when you find out? That will really help me determine what is going on here

steel vault
#

I need to step away soon but @ocean lagoon will drop any details we find.

pulsar lava
#

Thank you very much! I really appreciate it!

ocean lagoon
#

Okay we did some digging on our end - for reader WSC513124052010 it appears that it was stuck processing a payment from 2023-11-20T16:50:07.84Z - 2023-11-20T16:51:11.959Z (UTC time). There does appear to be something weird going on our end though, because the payment should've been successfully completed before that (it shouldn't have taken that long) and tehre are some logs on our end that imply the reader got in a bad state

#

We need to loop in some more people to do some additional digging, so it would really help if you could write into support and mention that you spoke to karbi on Discord so that I can find your ticket. When you write it, it would also be great if you could give some other reader serial numbers that are seeing the same thing happen