-
Notifications
You must be signed in to change notification settings - Fork 102
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
REST API validate endpoint fails with unexpected error 500 #421
Comments
@VihasMakwana |
I do have a customer where they used this connector already, but due to this error they removed it from the available connectors and now application teams are waiting before they can start sending to Splunk. For this customer it is urgent as we have some Splunk use casus with this connector that has to be finished before 1st April. |
@elekanne @rishabhbits038 you can set |
@VihasMakwana I've tested your suggestion but unfortunately it does not work for me
As you can see from stack trace, it does not even reach the
I guess the check should be done earlier? Before calling What do you think ? |
@vdesabou @ludovic-boutros @rishabhbits038 The proposed fix bypasses mandatory field validation, which will likely cause issues later during runtime.
Please take a look at the required parameters here. Let me know what you think. |
The problem is that validate endpoint is not supposed to return anything apart 200 with error_count being set, this was the case with earlier versions (here 2.0.9) and users want to get same behaviour as before: |
@VihasMakwana
|
The issue is that a unhandledConfig exception is being thrown. It wasn't happening with an older version because we were returning But with the new change, we are ignoring the result of I would suggest we only proceed with validity checks if there are no validation errors from |
I know there was weekend in between, but this is a blocking issue for the customer that Vincent @vdesabou is also (indirectly) working form. So any update on this would be appreciated. |
@VihasMakwana, thank you for the merged PR. |
I've tested merged PR with
{
"name": "com.splunk.kafka.connect.SplunkSinkConnector",
"error_count": 1,
"groups": [
"Common",
"Transforms",
"Predicates",
"Error Handling"
],
"configs": [
{
...
{
"definition": {
"name": "splunk.hec.uri",
"type": "STRING",
"required": true,
"default_value": null,
"importance": "HIGH",
"documentation": "Splunk HEC URIs. Either a list of FQDNs or IPs of all Splunk indexers, separated with a \",\", or a load balancer. The connector will load balance to indexers using round robin. Splunk Connector will round robin to this list of indexers. https://hec1.splunk.com:8088,https://hec2.splunk.com:8088,https://hec3.splunk.com:8088",
"group": null,
"width": "NONE",
"display_name": "splunk.hec.uri",
"dependents": [],
"order": -1
},
"value": {
"name": "splunk.hec.uri",
"value": null,
"recommended_values": [],
"errors": [
"Missing required configuration \"splunk.hec.uri\" which has no default value."
],
"visible": true
}
},
}
|
@vdesabou Do we now have a temporary setup that works when validation.disable is set or do we need to wait for the the real issue to be solved. If so @VihasMakwana what is needed and when do you think we can get that? |
I've compiled and tested with @VihasMakwana are you planning to do a release that includes the current merged PR ? |
@rishabhbits038 @vdesabou I've raised a PR #426 to resolve the remaining issue. |
Yes. |
Any idea when the release will be available ? |
@vdesabou maybe by today itself. I merged the other PR as well. |
@vdesabou FYI new release with above PRs https://github.com/splunk/kafka-connect-splunk/releases/tag/v2.2.1 |
Thanks a lot. We are planning to upload it to confluent hub as well |
Hello @VihasMakwana I am following up to ask if there will be a permanent solution for this issue without the use of |
I noticed a difference of behaviour when REST API validate endpoint is used between 2.0.9 and 2.0.10+ versions
When missing mandatory is not set, validate in 2.0.9 returns expected results, i.e 200 OK with error_count set, etc..
With 2.0.10+ it now returns 500 error
The change of behaviour between 2.0.9 and 2.1.0 is caused by this change made in #365
My understanding is that validate is not supposed to return error 500 but rather 200 with error_count set.
The text was updated successfully, but these errors were encountered: