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

Snow 1853185 jdbc driver v3.16 native okta http retry storm #2064

Open
wants to merge 85 commits into
base: master
Choose a base branch
from

Conversation

sfc-gh-fpawlowski
Copy link
Contributor

@sfc-gh-fpawlowski sfc-gh-fpawlowski commented Feb 5, 2025

Overview

SNOW-1853185

Pre-review self checklist

  • PR branch is updated with all the changes from master branch
  • The code is correctly formatted (run mvn -P check-style validate)
  • New public API is not unnecessary exposed (run mvn verify and inspect target/japicmp/japicmp.html)
  • The pull request name is prefixed with SNOW-XXXX:
  • Code is in compliance with internal logging requirements

External contributors - please answer these questions before submitting a pull request. Thanks!

  1. What GitHub issue is this PR addressing? Make sure that there is an accompanying issue to your PR.

    Issue: #NNNN

  2. Fill out the following pre-review checklist:

    • I am adding a new automated test(s) to verify correctness of my new code
    • I am adding new logging messages
    • I am modifying authorization mechanisms
    • I am adding new credentials
    • I am modifying OCSP code
    • I am adding a new dependency or upgrading an existing one
    • I am adding new public/protected component not marked with @SnowflakeJdbcInternalApi (note that public/protected methods/fields in classes marked with this annotation are already internal)
  3. Please describe how your code solves the related issue.

    Please write a short description of how your code change solves the related issue.

@sfc-gh-fpawlowski sfc-gh-fpawlowski self-assigned this Feb 5, 2025
@@ -503,6 +527,9 @@ public static CloseableHttpResponse execute(
requestIdStr,
requestInfoScrubbed,
backoffInMilli);
// TODO: shouldn't we sleep here for backoffInMilli - elapsedMilliForLastCall
// ?
// Thread.sleep(backoffInMilli - elapsedMilliForLastCall);
Thread.sleep(backoffInMilli);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Shouldn't we sleep here for backoffInMilli - elapsedMilliForLastCall?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think so. BackoffInMillis is calculated to be used as a time to sleep. Do you agree?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I would assume we may want to define 'backoff' as the time we want to have elapsed before sending the next request. In such way we would like to subtract the amount of time already spent for the processing, from the backoff-time - so the total waited time is correct.

It also seems to have been the original idea, taking for a word this comment:

// sleep for backoff - elapsed amount of time

However it is more like a clue for the future changes - not to be introduced in this PR.

@sfc-gh-fpawlowski sfc-gh-fpawlowski marked this pull request as ready for review February 10, 2025 01:07
try {
String newOneTimeToken = oneTimeTokenSupplier.apply(retryContext);
prepareFederatedFlowStep4Request(retrieveSamlRequest, ssoUrl, newOneTimeToken);
} catch (Exception e) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should we end with a Runtime exception here? I see that there were MalformedURLException | URISyntaxException so we can continue with SnowflakeSQLException, true? Could we use here handleFederatedFlowError?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's right - thanks - added

@@ -503,6 +527,9 @@ public static CloseableHttpResponse execute(
requestIdStr,
requestInfoScrubbed,
backoffInMilli);
// TODO: shouldn't we sleep here for backoffInMilli - elapsedMilliForLastCall
// ?
// Thread.sleep(backoffInMilli - elapsedMilliForLastCall);
Thread.sleep(backoffInMilli);
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think so. BackoffInMillis is calculated to be used as a time to sleep. Do you agree?

@@ -630,4 +643,28 @@ public void testOktaWithInvalidHostName() throws Throwable {
assertEquals((int) ErrorCode.IDP_INCORRECT_DESTINATION.getMessageCode(), ex.getErrorCode());
}
}

@Test
public void testOktaAuthRequestsAreRetriedUsingLoginRetryStrategy() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should we create the opposite test? I mean, where we confirme, then other login requests don't use RetryStrategy?

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.

4 participants