-
Notifications
You must be signed in to change notification settings - Fork 7
retry on 500s #111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
retry on 500s #111
Conversation
@klimburg Do you have more information. |
Yea so agree this needs to be fixed server side. If you want I can open an issue over in https://github.com/getslash/backslash to discuss options server-side. I think (but definitely not sure) what is happening here is that both I think one option would be to just retry the db transaction server side when deadlocks are detected. My rationale for retrying on the client side was just how painful it can be to have a slash process fail even though the test session itself passed. Given that not all the api requests are idempotent I get the desire not to generally retry on 500s. Logs
|
@klimburg I understand the reason that you opened it here, but you should not add 500 (internal server error) to retry. It should be fixed in server side. |
We noticed that occasionally we would see database deadlocks on
report_session_end
if asend_keepalive
was also sent at roughly the same time. This results in thereport_session_end
post raising on a 500.This adds
server_error
or status code 500 to the backslash client's retry list.