KAFKA-13756: Connect validate endpoint should return proper validatio…

[urbandan]

…n response when the connector.class is missing or invalid

More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.

Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.

Committer Checklist (excluded from commit message)

• Verify design and implementation
• Verify test coverage and CI build status
• Verify documentation (including upgrade notes)

[gharris1727]

Looks like this is a case that isn't addressed in #11369 .

I also like that the validation result will include the machine-readable recommended values now.

[urbandan]

@gharris1727 Can you please take a look at this PR? I addressed your comment.

[gharris1727]

@urbandan Thanks for addressing my comment.

Unfortunately I don't like this change to the Plugins interface surface area. I think the boolean flag and new methods duplicates the information exposed by the connectors() method.

I think a more typical arrangement for providing different error messages in different situations is to either throw a minimal message that can be wrapped by the caller to add context, or some callers dropping the error message completely.

I would also be okay with removing the list of plugins from the error message for other call-sites, since the list of plugins is already logged during startup and available via the REST API.

[urbandan]

@gharris1727 Thank you for the review. At first, I was hesitant to change the exception messages, but as you mentioned, it should be easy to get the list of plugins from the REST API. Simply removed the list from the message.

[gharris1727]

Hey @urbandan I was thinking more about this change as a whole, and how this will change how clients interact with connect.

There's some inertia for this API behavior: There may be callers of this API who don't have code for handling errors in connector.class if they were to be emitted in a 200 response. There may also be alerting built around the validate endpoint which attributes these 400 and 500 errors to the server administrators, in order to discover faulty plugin deployments. For backwards-compatible tooling, that tooling will need to support both styles of returning errors.

I do see the benefit in the change: it is more consistent to treat all of the config properties the same, instead of having special properties which escalate to 400s and 500s. It provides machine-readable recommended values without also needing to make a request to connector-plugins. If we were in greenfield development, I would certainly prefer your approach over the existing behavior.

But with the above trade-off, I don't think the benefits outweigh the risks. What sorts of benefits do you see, and how do you think we can manage these risks?

I apologize for asking these questions after two rounds of review, I didn't consider that callers will already be handling the existing behavior. I'll make sure to not accidentally waste any more of your time in the future.

[urbandan]

@gharris1727 No worries, thanks for taking the time to review the change!

We encountered this issue when integrating the Connect REST into an admin tool with a UI. As you mentioned, the connector.class issue results in a human-readable message, but the response cannot be properly parsed programmatically. This special handling of invalid connector.class values breaks the flow by using a different response code, and makes it hard to provide useful suggestions to the users.

The risk doesn't seem too high to me. I think the current behavior is incorrect, so fixing the API correctness outweighs the backward compatibility.
But if we stick to backward compatibility - can we add a flag (e.g. failOnInvalidClass) to the validate endpoint to specify the expected behavior around the connector.class? The default value (true) would keep the old behavior and result in a 400/500 response code, but if the client explicitly sets the flag to false, the endpoint would return a 200 response with recommendations. This way, the API itself wouldn't change, only the error message would be different (it wouldn't contain the list of available connector plugins).

[github-actions]

This PR is being marked as stale since it has not had any activity in 90 days. If you would like to keep this PR alive, please ask a committer for review. If the PR has merge conflicts, please update it with the latest from trunk (or appropriate release branch)

If this PR is no longer valid or desired, please feel free to close it. If no activity occurs in the next 30 days, it will be automatically closed.

[viktorsomogyi]

@urbandan would you please refresh your code? I also agree with you that in this case providing a proper error response outweighs backward compatibility. Besides, 4.0 may open up a good point to merge this.

[urbandan]

@viktorsomogyi Rebased it on latest trunk, Connect runtime tests were passing locally

[viktorsomogyi]

@gharris1727 would you mind if we submitted this in 4.0? I think this is a good time to merge this as it makes the response more usable, although it breaks the existing functionality (although I would say it fixes the endpoint). I think we can make this in 4.0, perhaps we could add a sentence about this in the upgrade notes.

[github-actions]

This PR is being marked as stale since it has not had any activity in 90 days. If you
would like to keep this PR alive, please leave a comment asking for a review. If the PR has
merge conflicts, update it with the latest from the base branch.

If you are having difficulty finding a reviewer, please reach out on the [mailing list](https://kafka.apache.org/contact).

If this PR is no longer valid or desired, please feel free to close it. If no activity occurs in the next 30 days, it will be automatically closed.

[github-actions]

This PR has been closed since it has not had any activity in 120 days. If you feel like this
was a mistake, or you would like to continue working on it, please feel free to re-open the
PR and ask for a review.