match .seeds with seeds.0

[matarrese]

Hello guys,
I' m having a look on this problem.
Can I ask which one should be the allowed behaviour?
if the value sent is:
"search.remote.my_cluster.seeds": null
seems that there is a missed match in AbstractScopedSettings:512
if (Regex.simpleMatch(entry, key) && canRemove.test(key)) {
entry value: search.remote.my_cluster.seeds
key value: search.remote.my_cluster.seeds.0
so, the simpleMatch fails and the key is not added as value to be removed.

Which behaviour should be accepted? Error or accepting the straight null value?
I wrote a simple solution that makes the match successful.
I don't know if it can be considered correct, please let me know your thought!
Closes #25953

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[rjernst]

I don't think this change is correct. If setting "foo": null, it would delete foo.bar if it existed, not just foo.0 etc.

[matarrese]

Hi @rjernst , thank you for your answer.
What's about if the second part after the dot must be another digit checked with a specific regular expression?

[rjernst]

It would work, but it becomes more costly to do the check. I think the real solution here is to fix the underlying problems with Settings and array value representation, as mentioned in #25953.

[matarrese]

Hi @rjernst , thank you for your update. I have a question
when you say that it should be fixed the underlying problem, is this keySet that should be represented in a different way?

[rjernst]

is this keySet that should be represented in a different way?

Yes. Right now, the keys of the internal settings map are "special" for arrays. This allows the values to always be String, even for an array setting. The key in this case is appended with ".INDEX" of the array value, so for {"foo":["hello"]}, the map looks like foo.1 -> hello. This is why arrays are so complicated to manipulated in Settings: there are multiple keys that must be adjusted together.

[cbuescher]

@matarrese I'm just revisiting this while reviewing some older open PRs. Does @rjernst answer makes sense to you? If so, can we close this PR?

[javanna]

Relates to #26878. I think that we can close this.