Strengthen field-caps responses wire test

[dnhatn]

Relates #83494

[elasticmachine]

Pinging @elastic/es-search (Team:Search)

[jtibshirani]

Thanks, this is good to have!

[javanna]

left a couple of comments, thanks for working on this.

Couple of thoughts I left on #83494 still apply I think: do we also test cases where the mapping hash does not come back from an older node, yet we write the response to another node, which may or may not support the mapping hash? One more thing I do in these cases is test reading the response from an older version by storing the older format in base64 obtained from the previous version, rather than simulated from the code of the current version.

[dnhatn]

@jtibshirani @javanna Thanks for reviews.

I think: do we also test cases where the mapping hash does not come back from an older node, yet we write the response to another node, which may or may not support the mapping hash?

I am not sure if we need this special test? Anyway, we have these scenarios covered in our tests: with and without mapping hash with different wire versions.

One more thing I do in these cases is test reading the response from an older version by storing the older format in base64 obtained from the previous version, rather than simulated from the code of the current version.

I can add this test, but I am not sure its benefit. Also, we prefer randomized tests for testing wire compact.

[javanna]

I am not sure if we need this special test? Anyway, we have these scenarios covered in our tests: with and without mapping hash with different wire versions.

Can you expand on why you find it a special test? I was thinking that in the context of CCS, the one I described is a real-life scenario that our tests may not cover, but I am happy to discuss this.

I can add this test, but I am not sure its benefit. Also, we prefer randomized tests for testing wire compact.

Agreed that randomized tests are good and what you are adding expands our current coverage, but we can only simulate what would be written if the stream output was set to a certain previous version, and there are no guarantees that that is what the previous version really writes? What I am suggesting is that we read from the real bits that the previous version writes. Do you see what I mean?

[dnhatn]

@javanna I understand your comments, and I think there's disagreement on testing BWC here.

I was thinking that in the context of CCS, the one I described is a real-life scenario that our tests may not cover, but I am happy to discuss this.

I think we should write BWC tests with cross clusters with mixed versions instead.

Agreed that randomized tests are good and what you are adding expands our current coverage, but we can only simulate what would be written if the stream output was set to a certain previous version, and there are no guarantees that that is what the previous version really writes? What I am suggesting is that we read from the real bits that the previous version writes. Do you see what I mean?

I don't see many of us doing this. I think we should write mixed cluster tests (e.g., #84455) instead.

Anyway, let's move on. I added the tests as you suggested. Would you please take another look? Thank you!

[javanna]

besides the comments I left, one minor peculiarity of these tests is that we create a list of index responses. Should we rather test using the FieldCapabilitiesNodeResponse which holds what we are creating in these tests?

[dnhatn]

@jtibshirani @javanna Thanks for reviews.