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-1623269 Fail sink task on authorization exception from Snowflake #916

Merged
merged 2 commits into from
Aug 26, 2024

Conversation

sfc-gh-mbobowski
Copy link
Contributor

@sfc-gh-mbobowski sfc-gh-mbobowski commented Aug 21, 2024

Overview

SNOW-1623269

Details of this error can be found in JIRA and comments left in the code. The fix is not very complicated but decided to hide it behind a parameter for safety reasons.

I tested this change end-to-end on sfctest0 cause it's tricky to test it automatically.

Pre-review checklist

  • This change should be part of a Behavior Change Release. See go/behavior-change.
  • This change has passed Merge gate tests
  • Snowpipe Changes
  • Snowpipe Streaming Changes
  • This change is TEST-ONLY
  • This change is README/Javadocs only
  • This change is protected by a config parameter enable.task.fail.on.authorization.errors.
    • Yes - Added end to end and Unit Tests.
    • No - Suggest why it is not param protected
  • Is his change protected by parameter <PARAMETER_NAME> on the server side?
    • The parameter/feature is not yet active in production (partial rollout or PrPr, see Changes for Unreleased Features and Fixes).
    • If there is an issue, it can be safely mitigated by turning the parameter off. This is also verified by a test (See go/ppp).

@sfc-gh-mbobowski sfc-gh-mbobowski requested a review from a team as a code owner August 21, 2024 13:40
Copy link

@sfc-gh-dseweryn sfc-gh-dseweryn left a comment

Choose a reason for hiding this comment

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

Generally LGTM, two minors

Comment on lines 21 to 22
boolean authorizationTaskFailureEnabled;
boolean authorizationErrorReported;

Choose a reason for hiding this comment

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

should these be private?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, done.

Comment on lines 42 to 54
public void reportPrecommitException(Exception ex) {
if (authorizationTaskFailureEnabled
&& ex.getMessage().contains(AUTHORIZATION_EXCEPTION_MESSAGE)) {
authorizationErrorReported = true;
}
}

/** Throw exception if authorization has failed before */
public void throwExceptionIfAuthorizationFailed() {
if (authorizationTaskFailureEnabled && authorizationErrorReported) {
throw ERROR_1005.getException();
}
}

Choose a reason for hiding this comment

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

I think that in reportPrecommitException() we do not need a feature check. toggling a field is not dangerous and gives us another possibility...

...in throwExceptionIfAuthorizationFailed() if the feature is disabled by default (can we check if it is default vs explicitly disabled?), we could add a warning log — something like:

Authorization problem detected. You may want to configure "enable.task.fail.on.authorization.errors = true" to make the connector automatically pickup rotated credentials

It could help users with discoverability and fixing problem on their own — WDYT?

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 think it might not be the best idea because of the following reasons:

  • failing task doesn't mean that it's going to be restarted. This behaviour is specific to Confluent platform.
  • authorization failure might happend from different reasons than key rotation
  • there would be a lot of this log as they would be produced on every put() call

Overall it's a good idea, but I have doubts about this specific scenario.

Choose a reason for hiding this comment

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

What you have just wrote could be a very fitting warning message then. We could create a latch to print it only once. Food for thought. Anyway — good job :)

@sfc-gh-mbobowski sfc-gh-mbobowski merged commit 56f96bb into master Aug 26, 2024
78 of 80 checks passed
@sfc-gh-mbobowski sfc-gh-mbobowski deleted the mbobowski-SNOW-1623269 branch August 26, 2024 07:42
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.

2 participants