Skip to content

Add chunked xcontent handling to SearchTemplateResponse#99184

Merged
romseygeek merged 15 commits intoelastic:mainfrom
romseygeek:xcontent/chunked-search-template
Apr 8, 2026
Merged

Add chunked xcontent handling to SearchTemplateResponse#99184
romseygeek merged 15 commits intoelastic:mainfrom
romseygeek:xcontent/chunked-search-template

Conversation

@romseygeek
Copy link
Copy Markdown
Contributor

Relates to #95661

@romseygeek romseygeek added :Search/Search Search-related issues that do not fall into other categories >refactoring v8.11.0 labels Sep 4, 2023
@romseygeek romseygeek self-assigned this Sep 4, 2023
@elasticsearchmachine
Copy link
Copy Markdown
Collaborator

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

@elasticsearchmachine elasticsearchmachine added the Team:Search Meta label for search team label Sep 4, 2023
@DaveCTurner
Copy link
Copy Markdown
Member

Seems ok to me, although I haven't gone through to verify that all the response-status handling works. Is that covered by enough other tests or does it need closer inspection?

@romseygeek
Copy link
Copy Markdown
Contributor Author

The status handling for multisearchtemplate is covered by YAML tests. We have a test that checks we get a 400 for a bad request in the searchtemplate tests, but I think those are handled elsewhere in the stack, and I'm not sure we have proper tests anywhere for non-200 responses due to things like shard failures. I'll take another look.

@romseygeek
Copy link
Copy Markdown
Contributor Author

Having looked again... RestRenderSearchTemplateAction does not need status handling. RestMultiSearchTemplateAction did not have status handling before, although it arguably should have some. RestSearchTemplateAction has the standard status handling of RestSearchAction, but as far as I can tell this is not actually tested anywhere for either the template or the standard action. I will open an issue to improve testing around status handling for searches more generally, but I don't think that needs to block this.

@mattc58 mattc58 added v8.12.0 and removed v8.11.0 labels Oct 4, 2023
@javanna javanna added :Search Foundations/Search Catch all for Search Foundations and removed :Search/Search Search-related issues that do not fall into other categories labels Jul 17, 2024
@drempapis
Copy link
Copy Markdown
Contributor

Hey @romseygeek, this PR has been open for a while. Are we still planning to merge it? If yes, could you please resolve the conflicts?

@romseygeek romseygeek requested a review from a team as a code owner April 7, 2026 14:38
@romseygeek
Copy link
Copy Markdown
Contributor Author

Wow, this is an old one. I've brought it up to date (and learned something about ref counting in the process).

@romseygeek
Copy link
Copy Markdown
Contributor Author

We'll also be able to close out the parent issue (#95661) once this is merged.

ElasticsearchException.generateFailureXContent(b, p, Item.this.getFailure(), true);
b.field(Fields.STATUS, ExceptionsHelper.status(Item.this.getFailure()).getStatus());
b.endObject();
return b;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This failure branch serializes the full error object as a single, non-chunked ToXContent. If an exception serializes a very large stack trace or metadata, this chunk could be large. I also checked other related commit and found that, for example, MultiSearchResponse handles failures by chunking them along the failure path.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I can use the same logic as in MultiSearchResponse, but it doesn't actually help much. The stack trace will still be a single chunk, as that is how ElasticsearchException.generateFailureXContent works.

return Iterators.concat(
ChunkedToXContentHelper.startObject(),
Item.this.getResponse().innerToXContentChunked(params),
Iterators.single((b, p) -> b.field(Fields.STATUS, Item.this.getResponse().status().getStatus())),
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

nit: Item.this.getFailure() could be replaced by getFailure(), in all places where it is applied

@drempapis
Copy link
Copy Markdown
Contributor

I will open an issue to improve testing around status handling for searches more generally, but I don't think that needs to block this.

@romseygeek, thank you for working on this. This is a nice, clean piece of work. I have a question: have you opened a ticket for handling searches? I 'd like to link it to the SearchInfra work.

@romseygeek
Copy link
Copy Markdown
Contributor Author

have you opened a ticket for handling searches?

I don't think I ever did open this, or at least if I did I can't find it anymore!

Copy link
Copy Markdown
Contributor

@drempapis drempapis left a comment

Choose a reason for hiding this comment

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

LGTM, ty Alan

@romseygeek romseygeek enabled auto-merge (squash) April 8, 2026 10:04
@romseygeek romseygeek merged commit d91b2c9 into elastic:main Apr 8, 2026
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/Search Catch all for Search Foundations Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch v9.4.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants