#uristri2_terminal-connection-token-timeout
torn ospreyBOT
👋 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/1463970627827273758
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
true iron
hello! the SDK fetches connected tokens pretty frequently, including when the SDK is initialized. is there a problem with that?
gaunt thorn
Tbh, I'm trying to solve an already discussed problem here:
#dev-help message and in email with Kent (subject Followup from Discord conversation with uristri2_api)
true iron
makes sense - most of the time if you already have a case open with us it's best to follow up on that thread directly, as the person working on that case will have context
gaunt thorn
The reality is that the case has already been closed. No solution was found.
We checked all the backend parameters and everything is in order. The issue is that the SDK occasionally throws a "Time out waiting for connection token" error.
This happens to us with more than 30 readers in different physical locations simultaneously.
We checked the SDK implementation, the Backend connection, the backend itself, and nothing.
My theory is that the SDK throws that error without even calling our callback to fetch the token.
true iron
interesting, can you share more about how you arrived at that theory? do you have logging that shows the error was thrown but a specific log line in your callback never showed or something along those lines?
gaunt thorn
Exact! We have logging when the callback is made, and in the process of understanding what was happening we also added RTT to the server-side call for fetching.
When we encountered that token connection error problem, the number of timeouts was much higher than the number of logged calls.
We checked the RTT and it was at 400ms, and furthermore, we checked and the Backend does not falter in the tide of error.
I'll send you screenshots of a specific case.
true iron
and just double checking, the logs you're referring to are client side right? so in the callback to fetch the connection token, and before a request to the server is made?
gaunt thorn
and just double checking, the logs you're referring to are client side right? so in the callback to fetch the connection token, and before a request to the server is made?
yep, client side
The error message on the screen is a bit exaggerated because there are logs that are repeated by timestamp. But the point I want to make is still clear.
other shop
torn ospreyBOT
wispy depot
Hi 👋
I'm stepping in as my colleague had to run. Give me a minute to catch up
wispy depot
Just so I am clear about the logging discrepancies, you are showing the fetchConnectionToken function is invoked but the callback function is not triggered and the timeout error is thrown.
Do you have logs that show that, every time the fetchConnectionToken function is invoked, your server responds successfully with a Connection token?
The reason I ask is, as I understand the situation, the callback would not be triggered if the connection to the server times out. So the discrepancy between the count fetchConnectionToken invocations and the callback are only a smoking gun if we can prove the server DID respond successfully (or with a failure).
gaunt thorn
If you look at my last screenshot of the merchantConnectionToken all calls report the status. There are request calls and then success calls when the token has been returned.
I corrected some columns in the filter
wispy depot
Okay great. But what I am asking is whether there are server side responses for every single time the fetchConnectionToken function was invoked. And specifically I want you to verify that there is a server response that corresponds to the fetchConnectionToken timeout errors.
gaunt thorn
from the same time range I have this logs from the server.
There's more calls as in the server logs we don't have per store logs
But you can see how the frontend logs have corresponding backend logs. Same timestamps.
wispy depot
Okay that does appear to have the necessary data to allow us to dig deeper. As with the last thread, this isn't something we can solve through a Discord chat.
I recommend you re-open the case and provide this information.
However, and this is critical, please provide the data in a .CSV and not through screenshots. Trying to work with pictures of data makes it more difficult to trace the operations from specific SDK operations to specific server-side API calls, which will be of the most importance in digging further here.
If you want to create a new case, I can send you a new link but I figure you probably still have a lot of context in the existing one
gaunt thorn
I'd say we stick with the open case. And I agree with you that CSV files are important because it's very difficult to work from screenshots.
I have the email thread with Kent but I'm not sure what the case number is
wispy depot
Okay great. Posting new messages should re-open the case
torn ospreyBOT