EZP-29253: Make session refresh re-try on timeouts and server errors

[andrerom]

In order to try to improve stability of rest client, re-try session refresh which is often the one holding others back on timeout and 5xx errors. Do this for up to 180 seconds which can happen on slow deployment / security updates of backend, on cases where service needs to be taken down and cache needs to be re-generated.

NOTE: This does not solve issues when backend is down and client sends other requests to it, for instance when session has just been refreshed. However 1. depending on the call that will have to be identified on a case by case basis, can't handle it generically afaik. 2. v2 solves this.

Todo:

• Rebase to right branch
• In case of 5xx errors, maybe add some sleep / wait time in order to make sure we can survive a up to 90 180 sec downtime / update / deployment window.

[jacek-foremski]

I tested the solution. It correctly retries the session refresh requests. However, after three requests (if all of them fail), the end result is the same - the Editor will see the login form. The reporter mentioned (and I also think that it would be a good idea) that Users should not be presented with the login form while they are logged in and still have a valid session - even if the session refresh requests are failing. Perhaps a better idea would be not to retry the requests, but let them fail silently (ofc without refreshing the session)?

[andrerom]

while they are logged in and still have a valid session

Do we have anyway of knowing that? Or you suggest we just assume it.

let them fail silently (ofc without refreshing the session)?

We could do that after 3 attempts, only thing I see as a problem is that if this endpoint is down, all other endpoints are probably down, and typically calls to other endpoints are just waiting for session refresh to complete before they are sent by client to server.

Unless of course we manage to get more details from customer on cases where this fails which is not related to deployment / server being restarted and such which is what I'm trying to cover with timeout and 5xx error handling. If we get something we can reproduce on that, I would be much more comfortable changing the logic here.

[jacek-foremski]

I was suggesting just assuming that the Editor still has a valid session. This is checked anyway on every request if I understand this correctly, so that shouldn't be an issue.
You are of course right in saying that if this endpoint is down, the other endpoints are also probably down. The reporter just seems to have an issue with showing the login form to the Editor when the errors happen (since the Editor is not really logged out).
In any case, I'll ask the reporter if retrying the session refresh requests is an acceptable solution for them and if not, I'll ask them to provide use case(s) not related to deployment.

[adamwojs]

Overall looks good. I'm missing only the configuration for the number of retries and timeout between then (maybe as the third parameter).

[jacek-foremski]

Should be (new Date()) - date (other way around).

[andrerom]

Indeed 😅

[andrerom]

Updated again, cleaned up for review.

[andrerom]

Merging to make aware on beta tag.