Skip to content

KAFKA-13306: Null connector config value passes validation, but fails creation#11333

Merged
mimaison merged 2 commits intoapache:trunkfrom
lhunyady:kafka-13306
Feb 11, 2022
Merged

KAFKA-13306: Null connector config value passes validation, but fails creation#11333
mimaison merged 2 commits intoapache:trunkfrom
lhunyady:kafka-13306

Conversation

@lhunyady
Copy link
Copy Markdown
Contributor

This patch adds null value check to the connector config validation, and extends unit tests to cover this functionality.

.collect(Collectors.joining(", "));

if (!keysWithNullValue.isEmpty()) {
throw new ConnectException(String.format("Null value found in config for key(s) %s", keysWithNullValue));
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Should this just be IllegalArgumentException?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Thank you for the comment, updated it in the latest commit.

}

@Test
public void testConfigValidationNullConfig() {
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Could you also add a test case with multiple null values as well?

Copy link
Copy Markdown
Contributor Author

@lhunyady lhunyady Sep 20, 2021

Choose a reason for hiding this comment

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

Thank you for the comment, updated it in the latest commit.

@lhunyady lhunyady force-pushed the kafka-13306 branch 2 times, most recently from ebef6c0 to b6013f7 Compare September 20, 2021 11:53
@lhunyady
Copy link
Copy Markdown
Contributor Author

@C0urante @kkonstantine Can you please review this change for me?

@C0urante
Copy link
Copy Markdown
Contributor

C0urante commented Sep 21, 2021

Thanks @lhunyady. I wonder if instead of throwing an exception we can add an error message to the offending config properties? This would allow other configuration errors to be surfaced immediately in calls to PUT /connector-plugins/{connectorClass}/config/validate instead of requiring users to issue a follow-up request, and would return a more standard request type than the 500 that I believe would be returned in response to an uncaught exception.

If this approach is desirable, we could implement it with an additional step in AbstractHerder::validateConnectorConfig that uses ConfigValue::addErrorMessage to report to the user that literal null values are not permitted in connector configurations, after adding a new ConfigValue for the offending property if one isn't already defined by the connector, the Connect framework, etc.

Thoughts?

@lhunyady
Copy link
Copy Markdown
Contributor Author

Thanks @C0urante for the feedback, I agree with you and updated the PR accordingly.

Copy link
Copy Markdown
Contributor

@C0urante C0urante left a comment

Choose a reason for hiding this comment

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

Thanks @lhunyady. I left a few comments but I was also wondering about an alternative approach that seems a little less verbose; I've drafted it on a personal branch (including the tests you've added in this PR, which both pass); what do you think?

https://github.com/C0urante/kafka/blob/e59b50a369390f8c6645103989e6eb17273931a3/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/AbstractHerder.java#L445-L451

Also, higher-level, I'm wondering if it might be easiest to just filter out null values from connectorProps instead of failing the connector? I'm a little hesitant to do that just because people might become reliant on this behavior but it's probably worth considering before we merge this PR.

Comment on lines 579 to 581
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Since this is no longer used in the main code base, could we remove it from this class and, where necessary, replace it either with a call to the new variant created below, or a testing-only wrapper function that has the same body as this one?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Nice cleanup 👍

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I believe that including the name of the property in the error message is redundant as that information will be available already in the REST response.

I also think we may want to be clearer about the error message here. Users can't supply null values, but developers (by specifying null as the default value for a property in a ConfigDef, for example) definitely can, and we may want to make it clear which variety we're prohibiting.

What do you think about this?

Suggested change
.map(configEntry -> new ConfigValueInfo(configEntry.getKey(), String.format("Null Value Not Allowed for key %s.", configEntry.getKey())))
.map(configEntry -> new ConfigValueInfo(configEntry.getKey(), "The JSON literal `null` may not be used in connector configurations"))

… creation

This patch adds null value check to the connector config validation, and extends unit tests to cover this functionality.

Co-authored-by: Chris Egerton <chrise@confluent.io>
… creation

This patch adds null value check to the connector config validation, and extends unit tests to cover this functionality.

Co-authored-by: Chris Egerton <chrise@confluent.io>
@lhunyady
Copy link
Copy Markdown
Contributor Author

lhunyady commented Jan 4, 2022

Thank you @C0urante, I have updated the pull request with your valuable suggestions.

Copy link
Copy Markdown
Contributor

@C0urante C0urante left a comment

Choose a reason for hiding this comment

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

LGTM, thanks @lhunyady!

@lhunyady
Copy link
Copy Markdown
Contributor Author

@C0urante what are the next steps to get this pull request merged?

@C0urante
Copy link
Copy Markdown
Contributor

@tombentley @kkonstantine would either of you have time for this small but valuable fix?

Copy link
Copy Markdown
Member

@mimaison mimaison left a comment

Choose a reason for hiding this comment

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

LGTM, thanks for the PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants