-
Notifications
You must be signed in to change notification settings - Fork 25.2k
testDataFrameTransformCrud failed with "Failed to retrieve checkpointing info" #44011
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
Comments
Pinging @elastic/ml-core |
"Failed to retrieve checkpointing info" is probably related to #43992 (comment). But then it appears that there's an additional problem with the HLRC when that happens, presumably because the stats object returned doesn't have the expected structure in this case. |
The 'Failed to retrieve checkpointing info' error is an outstanding issue the problem here is the failure to parse the response. The response object extends The options are to always return a code in the 2xx range and let the data frame client read any errors or add Best also modify the test to check for node and task failures. |
Data frame task responses had logic to return a HTTP 500 status code if there was any node or task failures even if other tasks in the same request reported correctly. This is different to how other task responses are handled where a 200 is always returned leaving the client should check for failures. Returning a 500 also breaks the high level rest client so always return a 200 Closes #44011
Data frame task responses had logic to return a HTTP 500 status code if there was any node or task failures even if other tasks in the same request reported correctly. This is different to how other task responses are handled where a 200 is always returned leaving the client should check for failures. Returning a 500 also breaks the high level rest client so always return a 200 Closes #44011
Data frame task responses had logic to return a HTTP 500 status code if there was any node or task failures even if other tasks in the same request reported correctly. This is different to how other task responses are handled where a 200 is always returned leaving the client should check for failures. Returning a 500 also breaks the high level rest client so always return a 200 Closes #44011
I see (very occasional) failures of
integTestRunnerorg.elasticsearch.xpack.dataframe.integration.DataFrameTransformIT.testDataFrameTransformCrud
:The exception looks like this:
Apparently you can ...
... but I had no success doing so.
The text was updated successfully, but these errors were encountered: