#zzz123
proud kayak
molten granite
Hi, is that set_reader_display a call against Stripe server? or inside the SDK? and also cancel_action?
thin furnace
Yeah, it's against stripe server
When I switch to VPN I am getting faster response
must be my network. weird.
molten granite
Likely
thin furnace
okay
molten granite
Hi, I think it's the network issue for 2 calls. And the turning off is weird. I suggest getting in touch with Support so they might be able to suggest some diagnose step, or eventually replacing your terminal
thin furnace
Okay - will get in touch with support regarding the power issues. Regarding the other issue. I am seeing a 30 second delay after calling https://api.stripe.com/v1/terminal/readers/tmr_xxx/cancel_action where the display cannot be set. I expect that after calling cancel_action, the reader would be immediately responsive to a subsequent set_reader_display call, but you must wait exactly 30 seconds until that is possible.
thin furnace
Yes, multiple times
molten granite
Let me clarify as I am not super familiar with terminals. Is cancel_action a call on your backend?
I am looking at this API Reference https://stripe.com/docs/api/terminal/readers/cancel_action
thin furnace
https://api.stripe.com/v1/terminal/readers/tmr_xxx/cancel_action is a call to the Stripe API. Once that request is received by stripe, it sends a response to the Stripe Terminal to cancel the current action (e.g. displaying the contents of the customer's cart to the screen).
molten granite
Okie let's look at this part. Did you observe the call from your frontend -> backend delayed for 30 seconds, or was it returned immediately but the terminal is unresponsive for 30 seconds?
thin furnace
I am calling curl-X POST https://api.stripe.com/v1/terminal/readers/tmr_xxx/cancel_action and it immediately clears the Terminal's screen. And then subsequent calls to curl https://api.stripe.com/v1/terminal/readers/tmr_xxx/set_reader_display will not have any effect until after 30 seconds.
There is no front-end, this is all being done from a linux bash terminal.
molten granite
I see. So the cancel happens immediately but somehow set_reader_display is ineffective in 30 seconds
Let's open another Support email thread, describing the issue clearly and include this Discord thread link. I believe it will reach our internal teams quickest. I will make sure to add a note into the email thread
thin furnace
Right. Okay
molten granite
I am sorry not being very helpful. When you are done let me know the email you used
thin furnace
No, that's alright. It seems like there is very little support for terminal owners, unfortunately.
thin furnace
I've uncovered some more details about this behavior. So, the https://api.stripe.com/v1/terminal/readers/tmr_xxx/cancel_action will cause that 30 unresponsiveness if the screen is in https://api.stripe.com/v1/terminal/readers/tmr_xxx/set_reader_display mode (as in, it is displaying the cart contents on the reader). So, if the screen is currently in idle mode, and not in cart mode, cancel_action can be called over and over again without triggering the 30 second delay. So, it is only if the reader is displaying the cart contents that this behavior is triggered.