Time out errors on backend and data requests

[john28650]

Question:
Is there a problem with wix-data API servers? Is there a way to stop time out errors like (WDE0028, WDE0073, WDE0110, etc)

Product:
Custom code done by a Wix Velo Master (forum title) on a Wix site

What are you trying to achieve:
Ever since I hired a Developer through the wix program and he updated my site and implemented wix-data api’s, my users are getting timeout errors all the time. The are getting randomly logged out multiple times per week, or getting a timeout screen. I need to solve this problem.

What have you already tried:
I have been talking with WIX advanced tech support but they have been thoroughly unhelpful.

Additional information:
The developer is telling me this is all an issue with Wix servers underperforming. (" Wix data failed to access the database collection, thus considering the session token invalid")
he tried to implement a data apadtor but it did not help. I am debating increasing rate limits and compute power by paying $50 a month more but don’t know if that will really help.

[anthony]

For error code WDE0028 this is indeed tied to a timeout. Backend functions have a timeout of 5 seconds. There are some steps to take to improve this which are detailed here.

As for the other errors these are not related to timeouts.

WDE0073 means that an item that didn’t exist was requested from a data collection. This would be an error either with the data in the collection missing or the code requesting an item that didn’t exist.

WDE0110 means a malformed / bad request. Likely a bug in the queries.

Using an external database is likely to resolve error 28, however 73/110 will still occur and are unrelated to the type of database being used.

[john28650]

Thank you for your reply, it is much appreciated. Do you have any idea why my users are getting logged out randomly?

" Wix data failed to access the database collection, thus considering the session token invalid"

this is what the developer is telling me is the reason, can you think of another reason it might be?

[anthony]

Not sure. Is the login using the standard Wix Members? Do you have any other error messages or short code examples that reproduce the error that you can provide?

[john28650]

No, I hired the developer because Wix log-in does not prevent a member from sharing log-in credentials and having multiple people logged in with the same account. My developer tells me the reason for the random log-outs is that the system is checking with the wix-data API to see if the member is valid and not logged in somewhere else. However, he says Wix servers are underperforming and returning a time-out error thus logging users out.

As you can see in the images below over the last 30 days there have been a lot of time-outs. Is this normal?

[anthony]

Here it seems like most of the time outs are coming from the check JWT function and very few of the requests are actually timing out (or erroring) relative to how many are being made (1,164 timeouts relative to 1,294,247 requests).

Is there error recovery?

Without knowing anything else about this function or how it’s used by the frontend code I can’t provide more help.

[giri-zano]

Anthony, correct me if I’m wrong, but it’s (backend) data request which have a 5 secs timeout. Backend FUNCTIONS have a standard timeout of anywhere between 1 and 5 minutes (so 1 minute , the grace period is what you can rely on before container times out), the frontend will only wait for 14 secs (unless on a more expensive plan, then it will wait for max 59 secs max) for a response from the backend.

[john28650]

The “checkJWT” function, checks the validity of the logged-in members’ sessions.

Yes, error recovery is implemented on the parts that access the database, and error catching is also implemented.

My developer just wrote me this. Does it make sense to you?

"The timeouts probably occur because there are way too much requests to access the same database collection, so WixData adapter might be in a situation where it tries to establish a connection to the collection while the collection is already connected to another instance

I don’t know what do Wix use as a Database provider, or what type of database they’re using, but clearly, something is not right in their wixData APIs or what it’s been built on

The timeout rate is 0.09%

This means my implementation works 99.91%

This rules out the possibility of poor implementation, and suggest a poor server performance"

[anthony]

@giri-zano

Anthony, correct me if I’m wrong, but it’s (backend) data request which have a 5 secs timeout. Backend FUNCTIONS have a standard timeout of anywhere between 1 and 5 minutes (so 1 minute , the grace period is what you can rely on before container times out), the frontend will only wait for 14 secs (unless on a more expensive plan, then it will wait for max 59 secs max) for a response from the backend.

Yes that is correct.

[anthony]

I have no doubt the implementation is robust but as mentioned without more information about the implementation, examples of the requests, and X-Wix-RequestId headers that are failing there’s not much I can help with.

My question regarding error recovery was a question on whether or not the small amount of timeouts matters. ie. Are these requests timing out, retrying, and then completing on a second try without the user intervening?

[john28650]

The Wix advanced support team is telling me something and my developer is telling me something very different can you please tell me who is correct?

Wix Support =

I have checked your site and could see the following code optimization issue that is a likely cause of the insistency due to concurrent code running at the same time.

To resolve the issue, do away with await keyword and use then promise(callback function) of the insert function to execute the return statement code.

This should improve your code functionality, hence resolve the errors.

Feel free to contact us again if you need any further assistance.
Have a good day.

Developer =

We have already done that since the start, here is a screenshot with the keywords highlighted.

Wix Support =

Hi,
Thank you for getting back to us.

Yes, the code has been highlighted but hasn’t been changed as per my recommendations in my very first response.

“To resolve the issue, do away with await keyword and use then promise(callback function) of the insert function to execute the return statement code.”

Developer =

Bro, it’s literally the same, Using async/await or Promise/then has the same outcome, But async/await is better for catching errors, Wix use runtime workers to run our JavaScript code, which in their case, Node.js … they technically can’t treat it differently, JavaScript code is universally the same everywhere

This whole thing is absurd. The code either works or not. If it work %99.91 of the times then nothing is wrong in the code.

Besides, the function doesn’t just get rejected (due to an error), it just hangs until the server terminate (timeout) the process, it means something is wrong with the server, not the code. All these issues started after the issue in their US server that THEY informed you about, the errors has been reduced thanks to the dataAdapter that I have developed, but the server issues are still there.

I don’t have access to their server to work my code around their “bugs”, and yet I’m required to come up with a “magical” code that works with their bugs!!

Wix don’t give developers access to “X-requestId” or other headers, and they’re asking you, the client, to provide them with such IDs, when even developers can’t access them and the only way to get them is to monitor the browser for hours hoping to catch an error and read its request ID"

Who is correct?

[john28650]

Also it appears the errors are getting worse comparing the last 7 days.

[anthony]

I believe there are a few things going on here:

1. Support is saying that removing the await keywords mentioned and replacing them with .then() will allow this function to return faster which is true. Code called on the backend continues to run for longer than the 14 seconds the frontend function will wait for the reply.
2. There are in fact WDE0028 errors coming back which I’ve reached out about internally.

I’m still not sure what could be happening with the checkJWT function timing out as I haven’t seen that code. My understanding is that this function is where the WDE0028 errors are occurring.

Per the first point, and since I don’t have the full picture of this site I don’t know what is going on here but to elaborate on what support was saying:

With async/await the function might do:

async function example() {
  await doSomething() // example() function pauses for 8 seconds waiting for doSomething() to complete
  moreCode() // doesn't execute until doSomething() is done
  anotherCall() // doesn't execute until doSomething() is done
  await doSomethingElse() // example() function pauses for 8 seconds waiting for doSomethingElse() to complete

  return true; // Function has now been running for 16 seconds, it times out on the frontend and returns WDE0028
}

What support is saying to do is:

function example() {
// doSomething() is called, it will take 8 seconds and when it's done then
// it will execute moreCode() and anotherCall() when
// but it doesn't make example() wait until it finishes
// example() can proceed executing its next line of code in a few milliseconds
  doSomething().then(() => {
    moreCode() // doesn't execute until doSomething() is done
    anotherCall() // doesn't execute until doSomething() is done
});

  doSomethingElse() // function will take 8 seconds, but example() can keep executing

  return true; // example() has now been running for a handful of milliseconds, it doesn't timeout
}

[john28650]

Thank you for the response and I understand what you are saying but my developer is saying he has already done that.

Dev

"I agree with that, whenever the promises are not dependent on each others, I run them all together at the same time using something called Promise.allSettled

So that’s already implemented

Despite that, all promises finish within 1.5 seconds, which is far less than the 5 seconds limit of WixData, and the 14 seconds limit of the request

I’m saying it’s already implemented. I’m already aware of the concept and the best way to implement it"

Outside Developer I asked his opinion on this issue.

"Wix team is arguing that you should not make request concurrently
Because it could cause server issues

Your dev is saying that as long as they are not co-dependant he runs them simultaneously

But
Wix argument seems to be wrong anyway
Your concurrency is bellow limit rates
So they should be processed simultaneously anyway

What I’m trying to say is that your dev is using the wrong argument to proof his point

But for the Wix answer I don’t think they are going to help you further if no change is made.
I’m sorry for you man"

I am getting conflicting info from Wix support and my dev and an outside dev. Can you please help me?

[anthony]

That all makes sense. My responses are based on the limited knowledge I have of how this system works and how long these functions take to execute. If they’re always consistently 1.5 seconds or so then that shouldn’t be an issue. However if there are situations where backend requests lag, whatever the reason, then this change would make this function more robust in those cases.

Another thing worth looking at (at least for the WDE0073 issue) if these and other function calls are co-dependent is eventual consistency and setting consistentRead: true in these cases.

I’ve raised the issue internally about WDE0028 so let’s see what they say. Can you also provide me with your ticket number? It would help to share with the team.

Lastly I’m simply providing what help I can to resolve these issues. This is less about right and wrong and more about figuring out a complex topic and ensuring we’ve exhausted all possibilities.

[john28650]

First off let me say thank you again Anthony for taking the time to explain this to me. I understand what you are saying that this is a complicated issue with no exact right or wrong. I am just stuck in the middle, trying to figure out how to save my customers. Here is the ticket number and I look forward to hearing back from your internal queries.

(Request 1810865799)

[john28650]

Just checking back to see if you had heard from your internal team?

Yesterday 11-07-23 the database pages kept returning a 500 error, I contacted support and they are looking into it but after 3 hours it returned to normal.

Are there server issues at WIx currently?

Here is the ticket from yesterday 249821043

[john28650]

Hello is there anyone that will help me???