Merge remote-tracking branch 'upstream/main'

Author: drempapis

build-tools-internal/gradle/wrapper/gradle-wrapper.properties

@@ -1,7 +1,7 @@
 distributionBase=GRADLE_USER_HOME
 distributionPath=wrapper/dists
-distributionSha256Sum=7ebdac923867a3cec0098302416d1e3c6c0c729fc4e2e05c10637a8af33a76c5
-distributionUrl=https\://services.gradle.org/distributions/gradle-8.12-all.zip
+distributionSha256Sum=296742a352f0b20ec14b143fb684965ad66086c7810b7b255dee216670716175
+distributionUrl=https\://services.gradle.org/distributions/gradle-8.12.1-all.zip
 networkTimeout=10000
 validateDistributionUrl=true
 zipStoreBase=GRADLE_USER_HOME

build-tools-internal/src/main/resources/minimumGradleVersion

@@ -1 +1 @@
-8.12
+8.12.1

docs/README.asciidoc

@@ -157,16 +157,15 @@ used for its modifiers:
   * `// TESTRESPONSE[skip:reason]`: Skip the assertions specified by this
   response.
 * `// TESTSETUP`: Marks this snippet as the "setup" for all other snippets in
-  this file. This is a somewhat natural way of structuring documentation. You
-  say "this is the data we use to explain this feature" then you add the
-  snippet that you mark `// TESTSETUP` and then every snippet will turn into
-  a test that runs the setup snippet first. See the "painless" docs for a file
-  that puts this to good use. This is fairly similar to `// TEST[setup:name]`
-  but rather than the setup defined in `docs/build.gradle` the setup is defined
-  right in the documentation file. In general, we should prefer `// TESTSETUP`
-  over `// TEST[setup:name]` because it makes it more clear what steps have to
-  be taken before the examples will work. Tip: `// TESTSETUP` can only be used
-  on the first snippet of a document.
+  this file. In order to enhance clarity and simplify understanding for readers,
+  a straightforward approach involves marking the first snippet in the documentation file with the 
+  `// TESTSETUP` marker. By doing so, it clearly indicates that this particular snippet serves as the setup 
+  or preparation step for all subsequent snippets in the file. 
+  This helps in explaining the necessary steps that need to be executed before running the examples.
+  Unlike the alternative convention `// TEST[setup:name]`, which relies on a setup defined in a separate file,
+  this convention brings the setup directly into the documentation file, making it more self-contained and reducing ambiguity.
+  By adopting this convention, users can easily identify and follow the correct sequence 
+  of steps to ensure that the examples provided in the documentation work as intended.
 * `// TEARDOWN`: Ends and cleans up a test series started with `// TESTSETUP` or
   `// TEST[setup:name]`. You can use `// TEARDOWN` to set up multiple tests in
   the same file.

docs/changelog/120291.yaml

@@ -0,0 +1,5 @@
+pr: 120291
+summary: ESQL - Allow full text functions disjunctions for non-full text functions
+area: ES|QL
+type: feature
+issues: []

docs/changelog/120527.yaml

@@ -0,0 +1,6 @@
+pr: 120930
+summary: Normalize negative scores for `text_similarity_reranker` retriever
+area: Ranking
+type: bug
+issues:
+ - 120201

docs/changelog/120930.yaml

@@ -0,0 +1,6 @@
+pr: 120937
+summary: Use the system index descriptor in the snapshot blob cache cleanup task
+area: Snapshot/Restore
+type: bug
+issues:
+ - 120518

docs/changelog/120937.yaml

@@ -112,7 +112,9 @@ it is necessary to use the search function, like <<esql-match>>, in a <<esql-whe
 directly after the <<esql-from>> source command, or close enough to it.
 Otherwise, the query will fail with a validation error.
 Another limitation is that any <<esql-where>> command containing a full-text search function
-cannot also use disjunctions (`OR`) unless all functions used in the OR clauses are full-text functions themselves.
+cannot use disjunctions (`OR`), unless:
+
+* All functions used in the OR clauses are full-text functions themselves, or scoring is not used
 
 For example, this query is valid:
 
@@ -131,19 +133,27 @@ FROM books
 | WHERE MATCH(author, "Faulkner")
 ----
 
-And this query will fail due to the disjunction:
+And this query that uses a disjunction will succeed:
 
 [source,esql]
 ----
 FROM books
+| WHERE MATCH(author, "Faulkner") OR QSTR("author: Hemingway")
+----
+
+However using scoring will fail because it uses a non full text function as part of the disjunction:
+
+[source,esql]
+----
+FROM books METADATA _score
 | WHERE MATCH(author, "Faulkner") OR author LIKE "Hemingway"
 ----
 
-However this query will succeed because it uses full text functions on both `OR` clauses:
+Scoring will work in the following query, as it uses full text functions on both `OR` clauses:
 
 [source,esql]
 ----
-FROM books
+FROM books METADATA _score
 | WHERE MATCH(author, "Faulkner") OR QSTR("author: Hemingway")
 ----
 

docs/reference/esql/esql-limitations.asciidoc

@@ -523,6 +523,23 @@ You have the following options:
 ** Then set up an <<inference-example-eland,{es} service inference endpoint>> with the `rerank` task type.
 ** Refer to the <<text-similarity-reranker-retriever-example-eland,example>> on this page for a step-by-step guide.
 
+[IMPORTANT]
+====
+Scores from the re-ranking process are normalized using the following formula before returned to the user,
+to avoid having negative scores.
+[source,text]
+----
+score = max(score, 0) + min(exp(score), 1)
+----
+Using the above, any initially negative scores are projected to (0, 1) and positive scores to [1, infinity).
+To revert back if needed, one can use:
+[source, text]
+----
+score = score - 1, if score >= 0
+score = ln(score), if score < 0
+----
+====
+
 ===== Parameters
 
 `retriever`::

docs/reference/search/retriever.asciidoc

@@ -145,15 +145,35 @@ The following example adds `my_analyzer` as a search analyzer to the `title` fie
 
 [source,JSON]
 ----
+{
   "mappings": {
     "properties": {
       "title": {
         "type": "text",
-        "search_analyzer": "my_analyzer",
-        "updateable": true
+        "search_analyzer": "my_analyzer"
+      }
+    }
+  },
+  "settings": {
+    "analysis": {
+      "analyzer": {
+        "my_analyzer": {
+          "tokenizer": "whitespace",
+          "filter": [
+            "synonyms_filter"
+          ]
+        }
+      },
+      "filter": {
+        "synonyms_filter": {
+          "type": "synonym",
+          "synonyms_path": "analysis/synonym-set.txt",
+          "updateable": true
+        }
       }
     }
   }
+}
 ----