Skip to content
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

Updated retry behaviour #125

Merged
merged 3 commits into from May 23, 2023
Merged

Conversation

rcypher-databricks
Copy link
Contributor

  • retry on 500 status codes if the server operation is idempotent
  • retry on request errors except: too many redirects, invalid protocol scheme, TLS cert verification failure
    Signed-off-by: Raymond Cypher raymond.cypher@databricks.com

- retry on 500 status codes if the server operation is idempotent
Signed-off-by: Raymond Cypher <raymond.cypher@databricks.com>
Allow retries on calls to fetch results.  The drivers handling of fetching result pages is robust enough to handle unexpected pagination due to retries.
Updated the error handling to make sure that the client error handler will be called so that information in databricks response headers will be added to the error info.
Signed-off-by: Raymond Cypher <raymond.cypher@databricks.com>
msg, start := logger.Track("ExecuteStatement")

// We use context.Background to fix a problem where on context done the query would not be cancelled.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you!

internal/client/client.go Outdated Show resolved Hide resolved
}

// 429 Too Many Requests or 503 service unavailable is recoverable. Sometimes the server puts
// a Retry-After response header to indicate when the server is
// available to start processing request from client.
if isRetryable(resp.StatusCode) {
return true, nil
if resp.StatusCode == http.StatusTooManyRequests || resp.StatusCode == http.StatusServiceUnavailable {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make it a call to the function?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gotta docuemnt that we do honour retry-after if it not 429 or 503

internal/client/client.go Outdated Show resolved Hide resolved
internal/client/client.go Outdated Show resolved Hide resolved
Simplified error message  to use either X-Databricks-Reason-Phrase or X-Thriftserver-Error-Message header.
Always honour Retry-After header when retrying.  Not just on 429 or 503.
Signed-off-by: Raymond Cypher <raymond.cypher@databricks.com>
}
}
return false, nil

// The error is likely recoverable so retry.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should probably not retry execute statement in case of network connection severed

@rcypher-databricks rcypher-databricks merged commit 2661951 into databricks:main May 23, 2023
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants