Merge branch 'main' into Anuj7411/register-anyscale-scaleway-ovhcloud

Author: andrescrz

.agents/commands/comet/_pr-description-sync.md

@@ -51,7 +51,7 @@ Clean up `$TMP` on exit.
 Apply the same logic as `/comet:create-pr` Step 6 (Extract Change Information) and Step 7 (Pre-fill PR Template). In particular:
 
 - Fill every `##` section defined in `.github/pull_request_template.md`. Sections not applicable to this PR get `N/A`, never get removed.
-- Re-derive the **Details** summary from the diff and commit messages.
+- Re-derive the **Details** section from the diff and commit messages in the style set by `/comet:create-pr` Step 7 — what changes for a user, short, bulleted, authoritative, no summary of the diff. Keep the shape the section already uses (Before / After, flat list, or a couple of lines) unless the change no longer fits it.
 - Re-derive the **Change checklist** from the file types changed (e.g., user-facing checked when UI files changed; documentation checked when `*.md` / `*.mdx` changed).
 - Keep the existing **Issues** ticket reference if present (e.g., `OPIK-6296`); if missing, infer from branch name.
 - Keep the existing **AI-WATERMARK** answers verbatim — never silently flip `yes`↔`no`.

.agents/commands/comet/create-pr.md

@@ -181,7 +181,20 @@ This workflow will:
   - **Fill every `##` section** in the template — the PR linter requires all sections to be present
   - If a section is not applicable, write "N/A" rather than removing it
 - **Section guidance**:
-  - **Details**: Implementation summary from git analysis (replace the HTML comment placeholder)
+  - **Details**: Replace the HTML comment placeholder with what changes for a user. A reviewer reads the diff for the code; this section tells them what is different when they use the product. Style:
+
+    - **Short.** Most PRs need 3–10 bullets. If it runs longer, the section is doing the diff's job — cut it.
+    - **Bullets, not prose paragraphs.** One behavior per bullet. Nest one level for sub-cases.
+    - **Authoritative.** State what happens: "The run is scored once." Not "This should now mean that the run will be scored once."
+    - **No fluff.** No motivation paragraph, no "this PR …", no approach summary, no benefits list, no restating the diff.
+    - **Observable behavior first.** What the UI shows, what the API returns, what gets scored, stored or logged. Name a class, method or file only when the behavior makes no sense without it.
+
+    Pick the shape that fits the change — do not force one:
+
+    - **Before / After bullet lists** when a behavior changed and the contrast is the point.
+    - **A flat bullet list** for a new capability, where there is no "before".
+    - **One or two lines** when users cannot see the change (refactor, dependency bump) — say what is unchanged and what improved, then stop.
+
   - **Change checklist**: Auto-check based on file types changed (user-facing for UI changes, documentation for docs)
   - **Issues**: Link to Jira ticket (e.g., `OPIK-2180`) or GitHub issue, or "NA" for hotfixes. List every ticket this PR **resolves** here with a normal hyphenated key.
   - **Jira key convention across the whole body** (see git-workflow rule): the GitHub for Jira app links any `OPIK-<digits>` it finds in the PR body to that ticket's Development panel, and the link can't be removed. So in **all** sections (Details, Testing, etc.) and in commit messages: tickets this PR **resolves** keep the hyphen (`OPIK-1234`) — links/URLs fine and wanted. Tickets **related but not resolved** here (escalations, references to older tickets — anything not in the title/branch) must be written with an underscore (`OPIK_7000`) and with **no** Jira URL (the URL contains the hyphenated key and links anyway). Apply this when generating every section below.

.agents/rules/git-workflow.mdc

@@ -28,6 +28,36 @@ Follow-up commits (preferred):
 ## PR Title
 `[<TICKET-KEY>] [COMPONENT] <type>: description`
 
+## PR Body
+Follow `.github/pull_request_template.md` — read the FULL template file before drafting.
+CI (`pr-lint`) fails the PR if any of these exact headings is missing:
+`## Details`, `## Change checklist`, `## Issues`, `## Testing`, `## Documentation`.
+Fill in `## AI-WATERMARK` too (Tools, Model(s), Scope, Human verification).
+Never substitute your own structure (e.g. `## Summary` / `## Test Plan`).
+A section that does not apply gets `N/A` — never delete a heading.
+
+### `## Details` — style
+Write what changes for a user. A reviewer reads the diff for the code; this section
+tells them what is different when they use the product.
+
+- **Short.** Most PRs need 3–10 bullets. If it runs longer, the section is doing the
+  diff's job — cut it.
+- **Bullets, not prose paragraphs.** One behavior per bullet. Nest one level for sub-cases.
+- **Authoritative.** State what happens: "The run is scored once." Not "This should now
+  mean that the run will be scored once."
+- **No fluff.** No motivation paragraph, no "this PR …", no approach summary, no
+  benefits list, no restating the diff.
+- **Observable behavior first.** What the UI shows, what the API returns, what gets
+  scored, stored or logged. Name a class, method or file only when the behavior makes
+  no sense without it.
+
+Pick the shape that fits the change — do not force one:
+
+- **Before / After bullet lists** when a behavior changed and the contrast is the point.
+- **A flat bullet list** for a new capability, where there is no "before".
+- **One or two lines** when users cannot see the change (refactor, dependency bump) —
+  say what is unchanged and what improved, then stop.
+
 ## Jira Key References (commit messages & PR body)
 The GitHub for Jira app links a PR to a ticket's Development panel whenever it finds an issue key matching `[A-Z][A-Z0-9]+-\d+` (project key, literal hyphen, digits) in the branch name, PR title, PR body, or any commit message. It matches on the regex alone — it cannot tell "this PR resolves the ticket" from "this just mentions it" — and the resulting link cannot be removed afterward. So free text must only contain hyphenated keys for tickets the PR actually resolves.
 

.agents/skills/documentation/SKILL.md

@@ -17,6 +17,24 @@ Use the repository template at `.github/pull_request_template.md` — read the F
 
 Also fill in the template's `## AI-WATERMARK` section (yes/no; if yes: Tools, Model(s), Scope, Human verification). Never invent a different structure such as `## Summary` / `## Test Plan`.
 
+A section that does not apply gets `N/A` — never delete a heading.
+
+### `## Details` — style
+
+Write what changes for a user. A reviewer reads the diff for the code; this section tells them what is different when they use the product.
+
+- **Short.** Most PRs need 3–10 bullets. If it runs longer, the section is doing the diff's job — cut it.
+- **Bullets, not prose paragraphs.** One behavior per bullet. Nest one level for sub-cases.
+- **Authoritative.** State what happens: "The run is scored once." Not "This should now mean that the run will be scored once."
+- **No fluff.** No motivation paragraph, no "this PR …", no approach summary, no benefits list, no restating the diff.
+- **Observable behavior first.** What the UI shows, what the API returns, what gets scored, stored or logged. Name a class, method or file only when the behavior makes no sense without it.
+
+Pick the shape that fits the change — do not force one:
+
+- **Before / After bullet lists** when a behavior changed and the contrast is the point.
+- **A flat bullet list** for a new capability, where there is no "before".
+- **One or two lines** when users cannot see the change (refactor, dependency bump) — say what is unchanged and what improved, then stop.
+
 ## Changelog Entry
 
 ```markdown

.agents/skills/opik-backend/testing.md

@@ -284,6 +284,31 @@ assertThat(actual)
 `containsExactly` asserts size and content together — `hasSize` plus per-index checks does not,
 and lets an extra element through.
 
+`hasSize` **on its own** is weaker still: it asserts a count and nothing about identity, so any
+bug that preserves the count passes. This bites hardest on de-duplication, merge, and upsert
+tests, where the count is exactly the thing a bug is most likely to keep right:
+
+```java
+// ❌ BAD - passes if the wrong revision survived, or if the duplicate was kept
+// and the distinct row dropped. Both keep the size at 2.
+assertThat(stored).hasSize(2);
+assertThat(version.itemsTotal()).isEqualTo(stored.size());
+
+// ✅ GOOD - names the rows that must survive, so a wrong-winner bug fails
+assertThat(stored)
+    .usingRecursiveFieldByFieldElementComparatorIgnoringFields(IGNORED_FIELDS_DATA_ITEM)
+    .containsExactlyInAnyOrder(winningDuplicate, distinctItem);
+assertThat(version.itemsTotal()).isEqualTo(stored.size());
+```
+
+Asserting a derived counter against `stored.size()` is good — it ties the counter to reality
+rather than to a literal — but it is only as strong as the assertion on `stored` itself. Pin the
+contents first, then tie the counter to them.
+
+Reuse the shared ignore-field constants (`IGNORED_FIELDS_DATA_ITEM` and friends) rather than
+declaring a local list: they already encode which server-generated fields are not part of the
+contract, and a local copy silently drifts from them.
+
 These `containsExactly*` variants compare elements with the element type's own `equals`, which is
 what you want for exact-valued models. When the elements carry `BigDecimal` or `double`, the same
 exception that justifies a comparator on a single object applies per element — otherwise a

.agents/skills/write-docs/SKILL.md

@@ -263,6 +263,24 @@ Use the repository template at `.github/pull_request_template.md` — read the F
 
 Also fill in the template's `## AI-WATERMARK` section (yes/no; if yes: Tools, Model(s), Scope, Human verification). Never invent a different structure such as `## Summary` / `## Test Plan`.
 
+A section that does not apply gets `N/A` — never delete a heading.
+
+### `## Details` — style
+
+Write what changes for a user. A reviewer reads the diff for the code; this section tells them what is different when they use the product.
+
+- **Short.** Most PRs need 3–10 bullets. If it runs longer, the section is doing the diff's job — cut it.
+- **Bullets, not prose paragraphs.** One behavior per bullet. Nest one level for sub-cases.
+- **Authoritative.** State what happens: "The run is scored once." Not "This should now mean that the run will be scored once."
+- **No fluff.** No motivation paragraph, no "this PR …", no approach summary, no benefits list, no restating the diff.
+- **Observable behavior first.** What the UI shows, what the API returns, what gets scored, stored or logged. Name a class, method or file only when the behavior makes no sense without it.
+
+Pick the shape that fits the change — do not force one:
+
+- **Before / After bullet lists** when a behavior changed and the contrast is the point.
+- **A flat bullet list** for a new capability, where there is no "before".
+- **One or two lines** when users cannot see the change (refactor, dependency bump) — say what is unchanged and what improved, then stop.
+
 ## Internationalized READMEs
 
 `readme_CN.md`, `readme_ES.md`, `readme_FR.md`, `readme_DE.md` are AI machine-translated from the English `README.md`.

.github/scripts/discover-backend-tests.sh

@@ -4,6 +4,12 @@ set -euo pipefail
 NUM_GROUPS=16
 UNIT_TIMEOUT=10
 INTEGRATION_TIMEOUT=20
+# Per-test timeout handed to JUnit, overriding the default in junit-platform.properties.
+# CI reruns failures 3 times, so a deterministic hang costs 4x these values: 8m against the 10m
+# unit wall, 16m against the 20m integration wall. Both must stay under their job timeout above,
+# or the job is cancelled before Surefire can name the offending test.
+UNIT_TEST_TIMEOUT=2m
+INTEGRATION_TEST_TIMEOUT=4m
 TEST_DIR="src/test/java"
 PATTERN="DropwizardAppExtensionProvider\|MySQLContainer\|ClickHouseContainer\|RedisContainer\|MinIOContainer"
 
@@ -62,9 +68,9 @@ done
 
 # Build JSON matrix: unit tests + N integration groups
 matrix="{\"include\":["
-matrix+="{\"name\":\"Unit Tests\",\"tests\":\"$unit_list\",\"timeout\":$UNIT_TIMEOUT}"
+matrix+="{\"name\":\"Unit Tests\",\"tests\":\"$unit_list\",\"timeout\":$UNIT_TIMEOUT,\"testTimeout\":\"$UNIT_TEST_TIMEOUT\"}"
 for ((i=1; i<=NUM_GROUPS; i++)); do
-  matrix+=",{\"name\":\"Integration Group $i\",\"tests\":\"${group_list[$i]}\",\"timeout\":$INTEGRATION_TIMEOUT}"
+  matrix+=",{\"name\":\"Integration Group $i\",\"tests\":\"${group_list[$i]}\",\"timeout\":$INTEGRATION_TIMEOUT,\"testTimeout\":\"$INTEGRATION_TEST_TIMEOUT\"}"
 done
 matrix+="]}"
 echo "matrix=$matrix" >> "$GITHUB_OUTPUT"

.github/workflows/backend_tests.yml

@@ -70,7 +70,7 @@ jobs:
                 fetch-depth: 1
 
             - name: Set up JDK 25
-              uses: actions/setup-java@v5
+              uses: actions/setup-java@v6
               with:
                 java-version: '25'
                 distribution: 'corretto'
@@ -84,6 +84,7 @@ jobs:
                 -Dtest="${{ matrix.tests }}"
                 -Dmaven.test.failure.ignore=true
                 -Dsurefire.rerunFailingTestsCount=3
+                -Djunit.jupiter.execution.timeout.testable.method.default="${{ matrix.testTimeout }}"
 
             - name: Publish Test Report
               uses: EnricoMi/publish-unit-test-result-action/linux@v2

.github/workflows/code_quality.yml

@@ -131,7 +131,7 @@ jobs:
 
       - name: Set up JDK 25
         if: matrix.leg.toolchain == 'java'
-        uses: actions/setup-java@v5
+        uses: actions/setup-java@v6
         with:
           java-version: "25"
           distribution: "corretto"

.github/workflows/sdks_generate_openapi_spec_and_fern_code.yml

@@ -23,7 +23,7 @@ jobs:
           persist-credentials: false
 
       - name: Set up JDK
-        uses: actions/setup-java@v5
+        uses: actions/setup-java@v6
         with:
           java-version: '25'
           distribution: 'corretto'