Merge branch 'main' into esql-unmute-array-index-percentile-test

Author: ivancea

docs/changelog/127563.yaml

@@ -0,0 +1,6 @@
+pr: 127563
+summary: "ESQL: Avoid unintended attribute removal"
+area: ES|QL
+type: bug
+issues:
+  - 127468

docs/changelog/128161.yaml

@@ -0,0 +1,6 @@
+pr: 128161
+summary: Fix system data streams incorrectly showing up in the list of template validation
+  problems
+area: Data streams
+type: bug
+issues: []

docs/reference/aggregations/_snippets/search-aggregations-metrics-percentile-aggregation-approximate.md

@@ -1,6 +1,6 @@
 There are many different algorithms to calculate percentiles. The naive implementation simply stores all the values in a sorted array. To find the 50th percentile, you simply find the value that is at `my_array[count(my_array) * 0.5]`.
 
-Clearly, the naive implementation does not scale — the sorted array grows linearly with the number of values in your dataset. To calculate percentiles across potentially billions of values in an Elasticsearch cluster, *approximate* percentiles are calculated.
+Clearly, the naive implementation does not scale — the sorted array grows linearly with the number of values in your dataset. To calculate percentiles across potentially billions of values in an Elasticsearch cluster, *approximate* percentiles are calculated.
 
 The algorithm used by the `percentile` metric is called TDigest (introduced by Ted Dunning in [Computing Accurate Quantiles using T-Digests](https://github.com/tdunning/t-digest/blob/master/docs/t-digest-paper/histo.pdf)).
 

docs/reference/aggregations/pipeline.md

@@ -230,7 +230,7 @@ An alternate syntax is supported to cope with aggregations or metrics which have
 
 ## Dealing with gaps in the data [gap-policy]
 
-Data in the real world is often noisy and sometimes contains **gaps** — places where data simply doesn’t exist. This can occur for a variety of reasons, the most common being:
+Data in the real world is often noisy and sometimes contains **gaps** — places where data simply doesn’t exist. This can occur for a variety of reasons, the most common being:
 
 * Documents falling into a bucket do not contain a required field
 * There are no documents matching the query for one or more buckets

docs/reference/aggregations/search-aggregations-bucket-composite-aggregation.md

@@ -606,7 +606,7 @@ PUT my-index-000001
 ```
 
 1. This index is sorted by `username` first then by `timestamp`.
-2. …​ in ascending order for the `username` field and in descending order for the `timestamp` field.1. could be used to optimize these composite aggregations:
+2. …  in ascending order for the `username` field and in descending order for the `timestamp` field.1. could be used to optimize these composite aggregations:
 
 
 

docs/reference/aggregations/search-aggregations-bucket-datehistogram-aggregation.md

@@ -679,7 +679,7 @@ Response:
 }
 ```
 
-The response will contain all the buckets having the relative day of the week as key : 1 for Monday, 2 for Tuesday…​ 7 for Sunday.
+The response will contain all the buckets having the relative day of the week as key : 1 for Monday, 2 for Tuesday…  7 for Sunday.
 
 
 

docs/reference/aggregations/search-aggregations-bucket-rare-terms-aggregation.md

@@ -7,7 +7,7 @@ mapped_pages:
 # Rare terms aggregation [search-aggregations-bucket-rare-terms-aggregation]
 
 
-A multi-bucket value source based aggregation which finds "rare" terms — terms that are at the long-tail of the distribution and are not frequent. Conceptually, this is like a `terms` aggregation that is sorted by `_count` ascending. As noted in the [terms aggregation docs](/reference/aggregations/search-aggregations-bucket-terms-aggregation.md#search-aggregations-bucket-terms-aggregation-order), actually ordering a `terms` agg by count ascending has unbounded error. Instead, you should use the `rare_terms` aggregation
+A multi-bucket value source based aggregation which finds "rare" terms — terms that are at the long-tail of the distribution and are not frequent. Conceptually, this is like a `terms` aggregation that is sorted by `_count` ascending. As noted in the [terms aggregation docs](/reference/aggregations/search-aggregations-bucket-terms-aggregation.md#search-aggregations-bucket-terms-aggregation-order), actually ordering a `terms` agg by count ascending has unbounded error. Instead, you should use the `rare_terms` aggregation
 
 ## Syntax [_syntax_3]
 
@@ -117,7 +117,7 @@ This does, however, mean that a large number of results can be returned if chose
 
 ## Max Bucket Limit [search-aggregations-bucket-rare-terms-aggregation-max-buckets]
 
-The Rare Terms aggregation is more liable to trip the `search.max_buckets` soft limit than other aggregations due to how it works. The `max_bucket` soft-limit is evaluated on a per-shard basis while the aggregation is collecting results. It is possible for a term to be "rare" on a shard but become "not rare" once all the shard results are merged together. This means that individual shards tend to collect more buckets than are truly rare, because they only have their own local view. This list is ultimately pruned to the correct, smaller list of rare terms on the coordinating node…​ but a shard may have already tripped the `max_buckets` soft limit and aborted the request.
+The Rare Terms aggregation is more liable to trip the `search.max_buckets` soft limit than other aggregations due to how it works. The `max_bucket` soft-limit is evaluated on a per-shard basis while the aggregation is collecting results. It is possible for a term to be "rare" on a shard but become "not rare" once all the shard results are merged together. This means that individual shards tend to collect more buckets than are truly rare, because they only have their own local view. This list is ultimately pruned to the correct, smaller list of rare terms on the coordinating node…  but a shard may have already tripped the `max_buckets` soft limit and aborted the request.
 
 When aggregating on fields that have potentially many "rare" terms, you may need to increase the `max_buckets` soft limit. Alternatively, you might need to find a way to filter the results to return fewer rare values (smaller time span, filter by category, etc), or re-evaluate your definition of "rare" (e.g. if something appears 100,000 times, is it truly "rare"?)
 

docs/reference/aggregations/search-aggregations-bucket-significanttext-aggregation.md

@@ -21,7 +21,7 @@ Re-analyzing *large* result sets will require a lot of time and memory. It is re
 * Suggesting "H5N1" when users search for "bird flu" to help expand queries
 * Suggesting keywords relating to stock symbol $ATI for use in an automated news classifier
 
-In these cases the words being selected are not simply the most popular terms in results. The most popular words tend to be very boring (*and, of, the, we, I, they* …​). The significant words are the ones that have undergone a significant change in popularity measured between a *foreground* and *background* set. If the term "H5N1" only exists in 5 documents in a 10 million document index and yet is found in 4 of the 100 documents that make up a user’s search results that is significant and probably very relevant to their search. 5/10,000,000 vs 4/100 is a big swing in frequency.
+In these cases the words being selected are not simply the most popular terms in results. The most popular words tend to be very boring (*and, of, the, we, I, they* … ). The significant words are the ones that have undergone a significant change in popularity measured between a *foreground* and *background* set. If the term "H5N1" only exists in 5 documents in a 10 million document index and yet is found in 4 of the 100 documents that make up a user’s search results that is significant and probably very relevant to their search. 5/10,000,000 vs 4/100 is a big swing in frequency.
 
 ## Basic use [_basic_use_2]
 

docs/reference/aggregations/search-aggregations-bucket-terms-aggregation.md

@@ -696,7 +696,7 @@ When aggregating on multiple indices the type of the aggregated field may not be
 
 ### Failed Trying to Format Bytes [_failed_trying_to_format_bytes]
 
-When running a terms aggregation (or other aggregation, but in practice usually terms) over multiple indices, you may get an error that starts with "Failed trying to format bytes…​".  This is usually caused by two of the indices not having the same mapping type for the field being aggregated.
+When running a terms aggregation (or other aggregation, but in practice usually terms) over multiple indices, you may get an error that starts with "Failed trying to format bytes… ".  This is usually caused by two of the indices not having the same mapping type for the field being aggregated.
 
 **Use an explicit `value_type`** Although it’s best to correct the mappings, you can work around this issue if the field is unmapped in one of the indices.  Setting the `value_type` parameter can resolve the issue by coercing the unmapped field into the correct type.
 

docs/reference/aggregations/search-aggregations-metrics-boxplot-aggregation.md

@@ -126,7 +126,7 @@ GET latency/_search
 1. Compression controls memory usage and approximation error
 
 
-The TDigest algorithm uses a number of "nodes" to approximate percentiles — the more nodes available, the higher the accuracy (and large memory footprint) proportional to the volume of data. The `compression` parameter limits the maximum number of nodes to `20 * compression`.
+The TDigest algorithm uses a number of "nodes" to approximate percentiles — the more nodes available, the higher the accuracy (and large memory footprint) proportional to the volume of data. The `compression` parameter limits the maximum number of nodes to `20 * compression`.
 
 Therefore, by increasing the compression value, you can increase the accuracy of your percentiles at the cost of more memory. Larger compression values also make the algorithm slower since the underlying tree data structure grows in size, resulting in more expensive operations. The default compression value is `100`.