Merge branch 'main' into security/genai/adhoc-alerts-index

Author: e40pud

docs/changelog/124825.yaml

@@ -0,0 +1,5 @@
+pr: 124825
+summary: Check alias during update
+area: Transform
+type: bug
+issues: []

docs/changelog/127371.yaml

@@ -0,0 +1,6 @@
+pr: 127371
+summary: Add cancellation support in `TransportGetAllocationStatsAction`
+area: Allocation
+type: feature
+issues:
+ - 123248

docs/changelog/127687.yaml

@@ -0,0 +1,6 @@
+pr: 127687
+summary: "ESQL: Fix alias removal in regex extraction with JOIN"
+area: ES|QL
+type: bug
+issues:
+  - 127467

docs/changelog/127924.yaml

@@ -0,0 +1,5 @@
+pr: 127924
+summary: Limit Replace function memory usage
+area: ES|QL
+type: enhancement
+issues: []

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"?)