In Unity we’ve set the trying setting the RetryConfigurations (and also tried the default ones)
private readonly RetryConfiguration retryConfiguration = new(500, 5, delegate(int retry, Retry retry1) { CustomLogger.LogWarning("retrying call"); });
And I’ve both tried to set it when doing the RPC request but also as the GlobalRetryConfiguration.
Then I do a Task.Delay(5000); and then have the client perform the RPC and before the RPC I disconnect the wifi, and also tried with the network link conditioner to have 100% packet loss. But I just quickly get a ‘TaskCanceledException’, no retries ever happen.
Any clue what I might be doing wrong? Thanks!
@lugehorsam might know better, however I’ll try and answer from memory;
The retry logic only acts on server errors that return status code 500+. These errors are classified as server internal errors and therefore safe to retry at some point in the future because the issue might have been resolved server side.
Hey @nixarn_tp what Mo described is currently the case; however handling timeouts with retries is something we can discuss internally.
Ok got it! Would be practical to get it via the client library so we don’t have to code our own solution. The rist with retries is of course the server can get the request even though the client never gets the response so the client needs to be aware how it behaves. Maybe you dont want that for all calls.
@nixarn_tp you’re right; we allow the retry configuration to be passed on a call-by-call basis (see the parameter list for any of our API methods.) All of Nakama’s calls are idempotent, meaning they can be safely retried without side-effects. But their is some care in custom RPC design that is required by developers to achieve the same effect.
We are discussing next steps later this week on how we decide to handle retrying client timeouts.
Hey @NixarnTowerPop, after some discussion we think adding retry behavior on client timeouts would actually introduce more problems than it would solve.
When a request times out, it is often due to poor client network conditions, which we suspect you are trying to solve for here. But as you alluded to earlier, there is no way for a client to know exactly whether a request timed out due to client conditions e.g., being in a bridge or tunnel, or if the server/database are at extremely high utilization.
As performant as Nakama is, we allow it to be extended in some very flexible ways (e.g., an RPC or custom SQL queries) and these can result in longer response times. In these cases, we wouldn’t want the client to retry on timeout because it was actually exacerbate any existing issues on the server.