#salteesam-terminal-timeouts

1 messages · Page 1 of 1 (latest)

agile bronzeBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

weary summit
#

Hey there

#

Do you have more information about what you see on your end when this happens?

vague surge
#

@delicate harbor hello, I'm also helping, like bismarck said, can you say more? like which point in time is the tiemout happening, what operation are you performing on your reader, etc.

delicate harbor
#

We are running a server-driven terminal sdk. and we are frequently running into the "Reader timeout" error. We do have retry logic in place, but it only seems to get resilved after the reader is restarted. https://stripe.com/docs/terminal/payments/collect-payment?terminal-sdk-platform=server-driven#reader-timeout

The documentation only mentions a network issue, but as we are running into it pretty frequently (and the only fix seems to be a terminal restart)
It happens when we are trying to send a payment intent to the reader

vague surge
#

It happens when we are trying to send a payment intent to the reader

  1. do you mean the processPayment() operation?

  2. is this happening across all readers?
    readers across a certain location?
    any type of grouping you can identfiy

delicate harbor
#
  1. the request is stripe.terminal.Reader.process_payment_intent
  2. they are all connect accounts associated to our account. It is happening with a bunch of readers accross many different locations
#

the error is not happening consistently, and there's nothing we can identify as being a common denomenator between them

vague surge
#

thanks, looking at the logs

agile bronzeBOT
vague surge
#

not seeing any logs for tmr_FWtn0gSImekWau which was the Reader for pi_3OLVrYFemSPDAV9918EchgQS at all for the entire day of 2023-12-09. Like, it seems that Reader was not on? Trying to see what I can glean from days before that

delicate harbor
#

okay thank you! i'll try to find some more examples of PIs too

vague surge
#

yeah can you find a more recent one please? that would help look quicker

delicate harbor
#

pi_3OLavaIol1CuUBvF0XIq6WeT
pi_3OJmObIol1CuUBvF3lO0V3er
pi_3OJmNbIol1CuUBvF2VOgKYer
pi_3OJmMaIol1CuUBvF33p1OfYF
pi_3OJm8zIol1CuUBvF2tG0jBHk

#

the top will be more recent than the bottom of that list

delicate harbor
#

let me know if those ones help!

proven tulip
#

👋 hopping in here as well to take a look - sorry for the wait

delicate harbor
#

no worries! thanks for looking

proven tulip
#

So from looking at the most recent intent pi_3OLavaIol1CuUBvF0XIq6WeT, it looks like there was a aflurry of disconnections right before/around the time the paymetn was attempted. Based on the logs we have on our end, seems to be due to poor connectivity

#

I'm seeing the same thing with pi_3OJmObIol1CuUBvF3lO0V3er and pi_3OJmNbIol1CuUBvF2VOgKYer

agile bronzeBOT
#

salteesam-terminal-timeouts

delicate harbor
#

Could these disconnections have anything to do with the hardware themselves? just with the sheer number of failures and the fact that it's spread across many locations its difficult to believe that they are all just from poor network connections. These customers have also ensured us they have never had any other network issues with the tablets/printers/ etc... that they use

proven tulip
#

As far as I can tell that's the only thing it could be, but I'm checking one last thing

delicate harbor
#

okay, appreciate it!

proven tulip
agile bronzeBOT