SearchRequest.searchAfter appends values instead of replacing: Bug or By Design?

Summary

When using the SearchRequest.Builder in the OpenSearch Java client (tested on version 2.15), calling the .searchAfter(...) method multiple times on the same builder appends new values to the existing searchAfter list, rather than replacing it. For example:

SearchRequest.Builder builder = new SearchRequest.Builder();
builder.searchAfter(FieldValue.of(1));
builder.searchAfter(FieldValue.of(2));
SearchRequest req = builder.build();
// Resulting searchAfter: [1, 2]

This behavior causes the searchAfter list to grow with each call, instead of being replaced with the latest values.

Expected Behavior

It's not clear whether this is a bug or by design. Typically, for similar builder-style APIs, repeated calls with the same field replace the previous value. If this is intended, please clarify in documentation. If not, this may cause confusion and should be addressed.

Actual Behavior

• Each call to .searchAfter(...) appends values to the list instead of replacing.
• Users expecting replacement may encounter unexpected behavior, especially when paginating results.

References

• SearchRequest.java code
• No explicit documentation clarifies whether this is intended.

Steps to Reproduce

1. Create a SearchRequest.Builder
2. Call .searchAfter(...) multiple times with different values
3. Build the request and inspect the searchAfter list

Questions

• Is this appending behavior by design for this API?
• Should the builder replace the previous list with each call?
• Would documentation clarification or an API change be recommended?

If this is by design, please clarify for future users. If not, recommend changing .searchAfter(...) to replace the previous values.

Version

• OpenSearch Java client: 2.15

Start with java-client/src/generated/java/org/opensearch/client/opensearch/core/SearchRequest.java and reproduce the repeated searchAfter calls described in the issue. Determine whether appending is intended for this builder API or whether replacement is expected, then establish the corresponding documentation clarification or API change as the definition of done.