#taha_code

1 messages · Page 1 of 1 (latest)

honest graniteBOT
#

👋 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/1339228958629298187

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

echo anvil
#

👋 happy to help

heavy gulch
#

Yes I am

#

Just wanted to know once a reader is discovered successfully, is there any timeout after which it needs re discover? or it always stays discovered?

honest graniteBOT
carmine compass
#

Hi there 👋 I'm not too sure I understand what you're asking.

Are you envisioning a flow where you don't call first check what readers are available, and instead just try to connect to one that you had discovered previously, when a reader becomes disconnected?

heavy gulch
#

No not really, my question is once a Stripe M2 reader has been discovered successfully, does it remain in a discovered state indefinitely, or is there a timeout after which it must be rediscovered? For example if there is no activity/transaction for a long period of time.

carmine compass
#

I'm not aware of anything like that, but you also usually wouldn't wait long between calling discoverReaders and connectReader.

#

discoverReaders returns a list of Reader objects for you to connect to, if you assume a previously discovered reader is still available when you call connectReader, but for some reason that discovered Reader isn't available anymore, then the request to connect to it will fail.

heavy gulch
#

Scenario is that the discoverReaders and connectReader is called and a transaction is performed successfully after which I call disconnectReader. So when next time a transaction is performed I will only call connectReader as the reader is already discovered.

carmine compass
#

Oh, that seems a little unusual. Do you have a reason for wanting to disconnect from the reader after each transaction?

heavy gulch
#

Yes due to multiple connectedAccounts

#

I am guessing there is no timeout for card reader. Only if it is rebooted then I will have to rediscover again.

carmine compass
#

Gotcha. As far as I know there isn't any sort of timeout there. Are you running into problems while testing this approach that are indicating there is some sort of timeout behavior that needs to be accounted for?

heavy gulch
#

Yes, if the reader is left unattended for a long time after a transaction is completed in disconnected state, it takes more time than usual to perform a transaction.

#

Thank you for your response

carmine compass
#

Any time!

Do you have more details about that subsequent transaction being slower? Have you stepped through the flow to figure out exactly which part(s) of the process are slower? Does performing a transaction in this context also include reconnecting to the reader, or are you just referring to processing a payment?

heavy gulch
#

I was wondering that the reader might be in rediscover state due to some timeout as from local logs I noticed that only the first time when discoverReaders is being called, it takes a bit more time.