Skip to content

Conversation

@pawankartik-elastic
Copy link
Contributor

MRT defaults to true for _search and false for _async_search. However, we'd want both to default to true for CPS.
An error is returned should the user try to set the value manually.

Fulfils CPS requirement S2D18.

…or CPS

MRT defaults to `true` for _search and `false` for _async_search.
However, we'd want it to default to `true` for both for CPS.

Fulfills CPS requirement S2D18.
@pawankartik-elastic pawankartik-elastic added >refactoring Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch :Search Foundations/CCS v9.2.0 labels Sep 29, 2025
@elasticsearchmachine elasticsearchmachine added the serverless-linked Added by automation, don't add manually label Sep 29, 2025
@pawankartik-elastic pawankartik-elastic marked this pull request as ready for review September 30, 2025 17:54
@pawankartik-elastic pawankartik-elastic requested review from a team as code owners September 30, 2025 17:54
@elasticsearchmachine
Copy link
Collaborator

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

Copy link
Contributor

@quux00 quux00 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First review completed with changes requested.

parser,
clusterSupportsFeature,
size -> failOnSizeSpecified(),
Optional.empty()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we know that none of the subclasses of this class are cross-project enabled? We'll need to track those down and ensure that this Optional.empty() is valid for all. Otherwise, that arg will need to be added to the parseInternalRequest method signature.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Irrespective of whether they're CPS-enabled or not, Optional.empty() could be a valid argument since:

  1. Their behaviour does not change for this value, and,
  2. This value can be a placeholder to denote that an endpoint does not need any CPS-specific handling during parsing.

Passing in true or false would've marked their behaviour more explicitly. I'd prefer evaluating their CPS compatibility and updating this value in a separate PR. Wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think I follow. If any CPS-enabled endpoints are using this AbstractBulkByQueryRestHandler class as a parent, then they must not pass in Optional.empty() because setting ccs_minimize_roundtrips is not allowed in that case. I doubt any bulk endpoints are CCS enabled, but we need to track them down to make sure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The two endpoints using AbstractBulkByQueryRestHandler are _update_by_query and _delete_by_query. They accept CCS patterns such as foo*,remote*:bar*. However, the remotes included are not affected. For example, /*,*:*/_delete_by_query does not affect the remotes' docs. Instead, I see weird errors. If I specify a single remote, I no longer get any errors, but the docs still don't get deleted. I'm assuming this is an oversight, and that these endpoints don't play well with Cross Cluster ops in the first place. In that case, Optional.empty() is the right value here.

Copy link
Contributor Author

@pawankartik-elastic pawankartik-elastic Oct 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, we should prevent Cross Cluster ops for them like we're planning to do for Fleet searches.
Edit: I just found tickets that track this internally.

@quux00
Copy link
Contributor

quux00 commented Sep 30, 2025

Also there aren't many tests added (even including the 2 you did the serverless env). I think I'd like to see details of manual testing of all the REST endpoints changed here to ensure that the ccs_minimize_roundtrips defaults come out as expected and also whether you are allowed to set it.

@pawankartik-elastic
Copy link
Contributor Author

Also there aren't many tests added (even including the 2 you did the serverless env). I think I'd like to see details of manual testing of all the REST endpoints changed here to ensure that the ccs_minimize_roundtrips defaults come out as expected and also whether you are allowed to set it.

I've refreshed the test in the serverless env, and here are the manual testing details: when CPS=true, _async_search, _search, and _search/template return an error only when MRT is explicitly set to either true or false. For CPS=false, there's no error whatsoever, irrespective of whether MRT is explicitly set or not. There's no change in the fleet endpoint's behaviour since CPS does not apply to it. I shared this matrix with you privately.

However, I have a question: does _rollup_search accept MRT value? It's not listed in its docs, but I don't get an error when I pass it. If I set MRT to false, I can see this value in TransportRollUpSearchAction, but it gets flipped to true when it goes through TSA.

@quux00
Copy link
Contributor

quux00 commented Oct 1, 2025

However, I have a question: does _rollup_search accept MRT value? It's not listed in its docs, but I don't get an error when I pass it. If I set MRT to false, I can see this value in TransportRollUpSearchAction, but it gets flipped to true when it goes through TSA.

Since it already accepts it (even if inappropriately) and rollup-search is not CSP enabled (and IIRC is not exposed in serverless?), we can just leave it as is.

Copy link
Member

@piergm piergm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clean changes @pawankartik-elastic LGTM!

@pawankartik-elastic pawankartik-elastic merged commit 391e78d into elastic:main Oct 3, 2025
35 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

>refactoring :Search Foundations/CCS serverless-linked Added by automation, don't add manually Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch v9.3.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants