Kev3200 - Terminal Session Expired | Stripe Developers | Page 1

dreamy rampart Apr 21, 2022, 7:02 PM

#

Hi 👋

So this is not an unexpected reader disconnect error?

wanton ember Apr 21, 2022, 7:06 PM

#

Hi as well 👋
And what platform are you using as the base that our terminal SDK is running on (JS, iOS, Android)?

wanton ember Apr 21, 2022, 7:52 PM

#

Hey @calm drift just wanted to check if you saw our follow-up questions?

calm drift Apr 21, 2022, 7:54 PM

#

Sorry, No not an unexpected disconnect

#

This is Android SDK

#

I've spread the error message properties out. This appears to be thrown/handled after a call to api.stripe.com/v1/payment_intents

Screen_Shot_2022-04-21_at_12.55.16_PM.png

#

and with our retry logic, subsequent calls also fail

#

our only solution at this point has been to restart the app

wanton ember Apr 21, 2022, 8:00 PM

#

Thanks for that! Hm, so it sounds like the connection token might be expiring. I'm not sure why that would be happening off the top of my head and will need a couple minutes to do some digging.

calm drift Apr 21, 2022, 8:11 PM

#

For context, these devices usually stay plugged in indefinitely as they are Kiosk units in restaurants. They also have a scheduled daily overnight restart.
From the Android SDK docs, it seemed like Terminal class should handle requesting a new connection token anytime it needs one, so to get this error, it feels like the token expired w/o Terminal "noticing"?

#

I also toyed with the idea of fetching a new token from our backend and calling Terminal.setConnectionToken on an X min. interval, while still supporting Terminal's onRequestConnectionToken. Thoughts on that?

wanton ember Apr 21, 2022, 8:23 PM

#

Hm, I'm honestly not certain off the top of my head, and am collaborating with some teammates that are a bit more familiar with these flows.

#

My read on the situation is similar to yours, that the SDK should be handling the token renewal process for you, but I might be misinterpreting something.

wanton ember Apr 21, 2022, 8:47 PM

#

Can you share what version of the Android Terminal SDK you're using?

calm drift Apr 21, 2022, 9:32 PM

#

Terminal version 2.7.1

valid ferry Apr 21, 2022, 9:43 PM

#

Hey there! Taking over for @wanton ember.

Thanks for that extra context. We're trying to get a holistic view of the situation (e.g. Terminal X connects, Y and Z requests happened successfully, then ConnectionToken is showing as expired).

Specifically we would need to see the below:

logs from the reader (e.g. reader object data: https://stripe.com/docs/api/terminal/readers/object#terminal_reader_object-id)
what requests it made and when, leading up to the ConnectionToken expiring

calm drift Apr 21, 2022, 10:27 PM

#

Might be a red herring, but I think it most typically happens after a long period (2-10 hrs) of inactivity.

For the first point, I don't have logs of the Reader object. We were only serializing the TerminalException on error caught, not the Reader. What in particular were you looking for out of this object?
In this session, the first api request is a POST to /payment_intents, which returns 401, which triggered exception handler with session_expired errorCode.

Before that ^ there is the initial session where app starts up, discovery is started, reader is connected to, request to POST /terminal/connection_tokens/activate, which returns 401, immediately followed by another request to same endpoint, which returns 200. Terminal PaymentStatus is set to READY
And then there was ~5hr of stripe-related inactivity (no calls to stripe api, just customers using device w/o purchasing anything), followed by the events in 2)

smoky wren Apr 21, 2022, 10:31 PM

#

👋 Hopping in as well - is it possible that during this period of inactivity that the reader connected to a different POS? I know that if a reader begins the connection process with another POS we immediately sever the existing connection which would result in the errors you're seeing

calm drift Apr 21, 2022, 11:25 PM

#

hmm possible but doubtful as we have checks for if a reader is disconnected from the app, which would have logged errors and should have auto-started discovery to try and reconnect to reader

#

When a reader is connected to one device, does it still broadcast as available to other devices to connect to during their own discovery? And if Device B were to attempt connection to Reader A, would that not trigger any errors on Device A, an unexpected disconnect maybe?

smoky wren Apr 21, 2022, 11:51 PM

#

When a reader is connected to one device, does it still broadcast as available to other devices to connect to during their own discovery?

Yes, I believe it would still show up as available to connect

#

And if Device B were to attempt connection to Reader A, would that not trigger any errors on Device A, an unexpected disconnect maybe?

This I'm less sure of - what kind of readers are you working with?

calm drift Apr 22, 2022, 12:05 AM

#

We have BBPOS Chippers

smoky wren Apr 22, 2022, 12:09 AM

#

Hmm... i'd expect those to trigger the unexpected disconnect

calm drift Apr 22, 2022, 12:11 AM

#

as would I :/ but we have a listener for that error and never saw it in the session logs

smoky wren Apr 22, 2022, 12:12 AM

#

Do you have the serial number of a chipper that recently saw this error, and a time range that I can look through for when the error occured?

calm drift Apr 22, 2022, 12:13 AM

#

^ Yes, let me fetch that.

Instead of trying to fix root cause, would it make sense if we catch a session_expired exception to fetch a new token and setConnectionToken() w/o waiting for Terminal to request one?

#

Serial: CHB202009000401
Timeframe: 4/21 (UTC 22:49 - 22:54)

#

/payment_intents returned a 401 at 22:53:13

smoky wren Apr 22, 2022, 12:19 AM

#

👍 Let m take a look

smoky wren Apr 22, 2022, 12:42 AM

#

Do you happen to have the exact error message from when the Payment Intent creation failed? In particular the last few digits of the expired api key

#

Also are you possibly using USB connections to connect to your chippers?

#

I think that you're attempting to connect over both bluetooth and USB, and those connections are overriding each other in unexpected ways

smoky wren Apr 22, 2022, 1:13 AM

#

@calm drift I'm heading out soon, but someone else should be hopping online to help! If your thread gets archived feel free to request that it get reopened

calm drift Apr 22, 2022, 1:18 AM

#

Ah yes we are using USB, I should have mentioned that earlier, my bad.

#

I can grab the last digits of apk key for you one sec

smoky wren Apr 22, 2022, 1:18 AM

#

Do you know if your code is attempting connections over both?

calm drift Apr 22, 2022, 1:18 AM

#

smoky wren I *think* that you're attempting to connect over both bluetooth and USB, and tho...

Are you able to tell if the connection attempts are both originating from the same device?

calm drift Apr 22, 2022, 1:19 AM

#

smoky wren Do you know if your code is attempting connections over both?

There should be logic to attempt usb first and use Bluetooth as a fallback, but as this is relatively new, it’s possible there’s a bug. However we have logs around when connectReader is called, for both USB and BT. We also have logic to prevent app from proceeding until Terminal reports a connectedReader. So if there were competing connection attempts during discovery, would Terminal be able to recognize an expired key at that time, or not until a stripe api method is called later during checkout flow?

calm drift Apr 22, 2022, 1:26 AM

#

smoky wren Do you happen to have the exact error message from when the Payment Intent creat...

Expired API Key provided: pss_live_YW***vC6G

smoky wren Apr 22, 2022, 1:34 AM

#

👍 Yeah that key matches what I see on my end - it was generated as part of the USB connection with CHB202009000401, but then just a couple minutes later a bluetooth connection was attempted (which expires the original key)

calm drift Apr 22, 2022, 1:37 AM

#

ahh ok that makes sense. That's a great lead on the issue for me to start debugging

#

And this also isn't happening for every kiosk so I guess, in summary, something about certain sessions is causing both USB and BT connection attempts, respectively, which invalidates the previous connection token. So then when Terminal tries to send request later, it fails.

calm drift Apr 22, 2022, 1:38 AM

#

smoky wren 👍 Yeah that key matches what I see on my end - it was generated as part of the ...

Did BT succeed?

smoky wren Apr 22, 2022, 1:38 AM

#

I think these requests may be coming in from different devices, but I don't know for sure (these are not requests that I look at often so I'm not 100% confident, but on my end it looks like different device UUIDs)

#

Yes, I think the BT connection succeeded

calm drift Apr 22, 2022, 1:40 AM

#

hmm ok I'll need to dig into this more, and probably add more logging around connection attempts. Thanks for the help so far. If you notice anything else, please lmk

calm drift Apr 22, 2022, 1:41 AM

#

smoky wren Yes, I think the BT connection succeeded

So should Terminal have thrown an unexpected disconnect in this case then?

polar maple Apr 22, 2022, 1:43 AM

#

Hi @calm drift I'll take over this thread, let me a sec to catch up

#

Thanks for waiting, I noticed that the reader was connected via USB first (https://dashboard.stripe.com/logs/req_GoAR49MSC0xU45), and few minutes later it was connected via Bluetooth (https://dashboard.stripe.com/logs/req_A1ko92fRTrwGcU). Is it because the first connection threw the session_expired error and that's why you changed to another connection type (e.g., Bluetooth)?

calm drift Apr 22, 2022, 1:59 AM

#

No the session expired error wasn’t noticed till after payment_intent creation attempt

#

I didn’t realize two connection attempts were made

polar maple Apr 22, 2022, 2:00 AM

#

I see, can you try to connect the reader with only one connection type (either USB or Bluetooth)?

calm drift Apr 22, 2022, 2:00 AM

#

Yea that’s what I thought we were doing, so I’ll need to debug our code to see why that happened

#Kev3200 - Terminal Session Expired