[es/nodes.info] Failed to decode response: Missing required property 'NodeInfoXpackSecurity.http' (JSON path: nodes.<node id>.settings.xpack.security #892
Comments
|
I just want to follow up to indicate, that this happened with (docker run):
When I explicitly added this:
It worked again for the first problem. The second problem seems to be related to having the anonymous realm created. We also were able to get past both using the approach I found in #891:
This seems like not the best idea moving forward, though. |
|
Hello! Thanks for reporting this. These are both errors in our API specification definition, I have already provided a fix for both of them, then we'll regenerate the client to fix the issues. The next patch has already been built, so this will probably end up in the next minor. |
l-trotta
added
Area: Specification
|
Hi @l-trotta , Thanks for your fix! I saw your PR for this: My impression is that this would fix the second of my error messages, but not the first. I do not believe it should be required to set I think this line should also have Thanks for your help to fix this! |
|
There's another PR for that :D |
|
Hi I have a very similar issue (on the same version of the client (8.15.2) and the same call (to es/nodes.info) I get this I can report this as a separate bug also, but they look very similar |
|
hey @karlney, this seems to be another issue, looks like the |
|
@l-trotta Thanks for all your prompt attention on these fixes. I am curious, is the server's configuration and API generated from these specifications as well, or does the spec just do its best to track and catch up with the actual server mechanics? The workaround you've posted with the suppression of the field validation has been a lifesaver, but I've always been curious why this new client has been subject to so many of these types of problems. |
this one ^^" |
|
I wonder if the server tests are robust enough that someone could experiment with generating the server-side API or config parsing from the same specifications. I appreciate that the HLRC and TransportClient before that brought it all kinds of heavy dependencies, but at least there wasn't a worry about being in sync with the server. Fundamentally this is a better choice, and I assume politics are involved, but the server should come from the same spec too. Some day. |
|
Hi @l-trotta , Noticed 8.15.3 client came out - but these fixes don't seem to be in it. Is that expected? Thanks! |
|
hey @marcreichman-pfi, yes it's expected, 8.15.3 was built before we could merge the PRs, so it will either be out in 8.15.4 or 8.16. |
|
Thanks! |
Java API client version
8.15.2
Java version
21
Elasticsearch Version
8.15.2
Problem description
When running the following Java code, this error happens, and it seems to depend on the state of the various xpack security settings. We've seen different combinations based on if security is off, or if it's on and there are no added users, etc.. -- We have not tried every combination of server settings. There are some scenarios where it works fine as well, but where it does not, there is not any way to work around this since we cannot enforce a specific security configuration to every installation.
Java code to reproduce
Either
Example stack traces (they vary..):
The text was updated successfully, but these errors were encountered: