Select the native tuple Server 3.5.0 and chart 1.3.0

docs/deployment.md

@@ -268,8 +268,63 @@ command-level Compose examples in the
 [Official Image + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose)
 section.
 
+### Upgrading to Server 3.5.0 {#native-schema-upgrade-3-5}
+
+Server 3.5.0 adds one native-only table, `dw_run_command_contracts`. The
+native schema moves from 11 to 12 on MySQL, MariaDB and PostgreSQL, and from
+10 to 11 on SQLite. The upgrade creates the table and its index and rewrites
+no rows. Server 3.4.x has the same schema as 3.3.x, so this is the only schema
+step from 3.3.x or 3.4.x. A 3.5.0 Server started on the earlier schema refuses
+with `native_schema_upgrade_required`.
+
+For the single-node Compose deployment:
+
+1. Stop the Server and leave MySQL running:
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml stop server
+   ```
+2. Back up MySQL and `server_storage`, and record the current image
+   reference. This backup is the only way back to 3.4.x.
+3. Change `DW_SERVER_IMAGE` to the 3.5.0 image, pull it and run
+   `schema-upgrade` once:
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml pull server
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml run --rm --no-deps server schema-upgrade
+   ```
+
+   It prints the schema versions before and after, for example
+   `"from_schema_version":11,"schema_version":12,"status":"upgraded"`. Run
+   again on a current database, it reports `"status":"current"`.
+4. Start the Server with
+   `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait`,
+   then confirm `/api/ready`, `/api/cluster/info` (`version` is `3.5.0`) and
+   worker registration.
+
+On MySQL and MariaDB, an interrupted upgrade resumes when you run
+`schema-upgrade` again. Rolling back to 3.4.x needs the backup: a 3.4.x Server
+refuses the upgraded database with `native_schema_newer_than_binary`. From
+3.0.x through 3.2.x, the same command also applies the earlier steps described
+in the next section. The worker protocol stays at `1.20` and the control plane
+at version `2`.
+
+What changes for running workflows is in the
+[3.5.0 release notes](https://github.com/durable-workflow/server/releases/tag/3.5.0):
+updates for runs started before their worker registered now bind that worker's
+contract instead of being rejected, sticky execution with history suffixes,
+and expired runs pruned every minute by the maintenance loop.
+
 ### Upgrading from Server 3.0.x to 3.3.2 {#native-schema-upgrade-3-0-to-3-3}
 
+These are the earlier schema steps. If you go from 3.0.x straight to 3.5.0,
+use the 3.5.0 image in step 3; its `schema-upgrade` applies these steps and the
+3.5.0 step together, and the notes on PostgreSQL index builds and MySQL
+resumption below still apply.
+
 Server 3.3.2 crosses three minor releases from 3.0.x and changes the native
 schema. On MySQL, MariaDB and PostgreSQL it moves from version 8 (3.0.x and
 3.1.0) through 10 (3.2.0) to 11 (3.3.0 to 3.3.2). On SQLite it moves from 8
@@ -609,6 +664,17 @@ only when Helm's `lookup` shows every Server stopped. Argo CD, Flux and
 instead. A `helm rollback` to a chart 1.0.x revision does not bring the Server
 back, because 3.0.x refuses the upgraded database: restore the backup instead.
 
+Chart 1.2.0 moves the default image to Server 3.4.0 with no schema change, so
+a plain `helm upgrade` from chart 1.1.0 is enough. Native pods also gain a
+`preStop` sleep (`native.preStopSleepSeconds`, default 5) and a 70-second
+termination grace period. Chart 1.3.0 moves the default image to Server 3.5.0,
+which needs the [schema upgrade from 11 to 12](#native-schema-upgrade-3-5):
+scale the Server to zero, back up the database, and run `helm upgrade` with
+`native.schemaUpgrade.enabled=true` (or the manual Job), then scale back up.
+See the chart's
+[Chart 1.3.0 / Server 3.5.0 notes](%%artifact.helmChartUpgradeUrl%%#chart-130--server-350-native).
+Going back to chart 1.2.0 means restoring that backup.
+
 ### Choosing a chart release {#helm-chart-selection}
 
 One chart release records the Server image it was tested against in `Chart.yaml`'s `appVersion`; the chart and Server have independent version numbers. The selected [compatibility tuple](./compatibility.md#last-qualified-reproducible-tuple) pairs chart **%%artifact.helmChartVersion%%** with Server **%%artifact.helmChartAppVersion%%**, from the same release metadata as the table and install command. Its [published OCI/package receipt](%%artifact.helmChartQualificationUrl%%) verifies that pairing, not a fresh Kubernetes installation.

docs/polyglot/server.md

@@ -516,11 +516,11 @@ curl http://localhost:8080/api/cluster/info \
 
 Returns the build identity, capability flags, protocol manifests, limits and
 discovery for the namespace named by `X-Namespace` (or the `namespace` query
-parameter, else `default`). Abridged output from the 3.3.2 image:
+parameter, else `default`). Abridged output from the 3.5.0 image:
 
 ```json
 {
-  "version": "3.3.2",
+  "version": "3.5.0",
   "implementation": "rust",
   "development": false,
   "server_id": "2145ce2abb12",
@@ -561,6 +561,9 @@ parameter, else `default`). Abridged output from the 3.3.2 image:
       "supported_workflow_task_commands": ["schedule_activity", "start_timer", "complete_workflow", "..."],
       "query_tasks": true,
       "workflow_updates": true,
+      "sticky_execution": { "supported": true, "...": "..." },
+      "sticky_history_suffix": { "supported": true, "version": 1 },
+      "activity_workflow_continuation": { "version": 1, "...": "..." },
       "...": "..."
     }
   },
@@ -586,11 +589,15 @@ Key field notes for client code:
 - The build version is `version`, not `server_version`. `implementation` is
   `"rust"` on the native Server.
 - Check `control_plane.version` and `worker_protocol.version` before calling
-  the API. Native 3.3.2 serves control plane `2` and worker protocol `1.20`,
+  the API. Native 3.5.0 serves control plane `2` and worker protocol `1.20`,
   and accepts worker requests that send any protocol version from `1.0` to
   `1.20`.
 - Workflow-task commands live under
   `worker_protocol.server_capabilities.supported_workflow_task_commands`.
+- Since 3.5.0, `worker_protocol.server_capabilities` advertises
+  `sticky_execution` and `sticky_history_suffix`. Since 3.4.0 it advertises
+  `activity_workflow_continuation`, which a worker uses only after its own
+  opt-in.
 - A capability flag set to `false` names a feature or published contract that
   native does not serve. `response_compression` is empty because native sends
   uncompressed responses.

i18n/de/docusaurus-plugin-content-docs/current/deployment.md

@@ -195,8 +195,39 @@ Upgrade-Reihenfolge:
 
 Der native Server prüft sein Schema beim Start. Patch-Veröffentlichungen innerhalb einer nativen Minor-Linie behalten das Schema bei, daher genügt ein Image-Wechsel. Eine Veröffentlichung, deren Hinweise eine Schemaänderung ankündigen, benötigt zusätzlich den Befehl `schema-upgrade` des Images, ausgeführt nach einer Datenbanksicherung, während alle Server gestoppt sind. Die Server-Referenz enthält aktuelle Compose-Befehlsbeispiele unter [Offizielles Image + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose).
 
+### Upgrade auf Server 3.5.0 {#native-schema-upgrade-3-5}
+
+Server 3.5.0 fügt eine nur native Tabelle hinzu, `dw_run_command_contracts`. Das native Schema wechselt auf MySQL, MariaDB und PostgreSQL von 11 auf 12 und auf SQLite von 10 auf 11. Das Upgrade legt die Tabelle und ihren Index an und schreibt keine Zeilen um. Server 3.4.x hat dasselbe Schema wie 3.3.x, daher ist dies von 3.3.x oder 3.4.x aus der einzige Schemaschritt. Ein Server 3.5.0, der auf dem früheren Schema gestartet wird, verweigert den Start mit `native_schema_upgrade_required`.
+
+Für die Compose-Bereitstellung auf einem einzelnen Knoten:
+
+1. Stoppen Sie den Server und lassen Sie MySQL weiterlaufen:
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml stop server
+   ```
+2. Sichern Sie MySQL und `server_storage` und halten Sie die aktuelle Image-Referenz fest. Diese Sicherung ist der einzige Weg zurück zu 3.4.x.
+3. Ändern Sie `DW_SERVER_IMAGE` auf das 3.5.0-Image, rufen Sie es ab und führen Sie `schema-upgrade` einmal aus:
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml pull server
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml run --rm --no-deps server schema-upgrade
+   ```
+
+   Der Befehl gibt die Schemaversionen vorher und nachher aus, zum Beispiel `"from_schema_version":11,"schema_version":12,"status":"upgraded"`. Erneut auf einer aktuellen Datenbank ausgeführt, meldet er `"status":"current"`.
+4. Starten Sie den Server mit `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait` und bestätigen Sie dann `/api/ready`, `/api/cluster/info` (`version` ist `3.5.0`) und die Worker-Registrierung.
+
+Auf MySQL und MariaDB wird ein unterbrochenes Upgrade fortgesetzt, wenn Sie `schema-upgrade` erneut ausführen. Ein Rollback auf 3.4.x erfordert die Sicherung: Ein 3.4.x-Server verweigert die aktualisierte Datenbank mit `native_schema_newer_than_binary`. Von 3.0.x bis 3.2.x wendet derselbe Befehl auch die früheren Schritte aus dem nächsten Abschnitt an. Das Worker-Protokoll bleibt bei `1.20` und die Steuerungsebene bei Version `2`.
+
+Was sich für laufende Workflows ändert, steht in den [Versionshinweisen zu 3.5.0](https://github.com/durable-workflow/server/releases/tag/3.5.0): Updates für Ausführungen, die gestartet wurden, bevor ihr Worker sich registriert hat, binden jetzt den Vertrag dieses Workers, statt abgelehnt zu werden; Sticky Execution mit History-Suffixen; und abgelaufene Ausführungen werden von der Wartungsschleife jede Minute bereinigt.
+
 ### Upgrade von Server 3.0.x auf 3.3.2 {#native-schema-upgrade-3-0-to-3-3}
 
+Dies sind die früheren Schemaschritte. Wenn Sie von 3.0.x direkt auf 3.5.0 wechseln, verwenden Sie in Schritt 3 das 3.5.0-Image. Sein `schema-upgrade` wendet diese Schritte und den Schritt für 3.5.0 gemeinsam an, und die Hinweise unten zu PostgreSQL-Indexaufbau und Fortsetzung auf MySQL gelten weiterhin.
+
 Server 3.3.2 liegt drei Minor-Veröffentlichungen nach 3.0.x und ändert das native Schema. Auf MySQL, MariaDB und PostgreSQL wechselt es von Version 8 (3.0.x und 3.1.0) über 10 (3.2.0) auf 11 (3.3.0 bis 3.3.2). Auf SQLite wechselt es von 8 auf 10. Ein Server aktualisiert sein Schema nie beim Start: 3.3.2 verweigert auf einer Datenbank mit Version 8 den Start mit `native_schema_upgrade_required`, daher kann der neue Server nicht starten, wenn nur `DW_SERVER_IMAGE` geändert wird. Der Befehl `schema-upgrade` des 3.3.2-Images aktualisiert eine Datenbank mit Version 8 direkt. Die [Upgrade-Hinweise zu 3.3.0](https://github.com/durable-workflow/server/blob/3.3.2/docs/releases/3.3.0.md#upgrade) beschreiben den Schritt, und die [Hinweise zu Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) des Helm-Charts führen die Schemaschritte und die Laufzeitänderungen von 3.0.5 auf 3.3.2 auf.
 
 Für die Compose-Bereitstellung auf einem einzelnen Knoten:
@@ -438,6 +469,8 @@ Ein bestehender PHP-2.x-Release wechselt bei einem gewöhnlichen Upgrade nicht a
 
 Chart 1.1.0 ändert das Standard-Image von Server 3.0.5 auf 3.3.2, das das [native Schema-Upgrade](#native-schema-upgrade-3-0-to-3-3) von 8 auf 11 erfordert. Ein gewöhnliches `helm upgrade` von Chart 1.0.x ändert nur das Image, und die neuen Pods verweigern den Start mit `native_schema_upgrade_required`. Folgen Sie den [Schritten zu Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) des Charts: Skalieren Sie den Server bei ausgeschaltetem Autoscaling auf null, sichern Sie die Datenbank und führen Sie dann das Upgrade auf Chart 1.1.0 mit `native.schemaUpgrade.enabled=true` aus. Sein `pre-upgrade`-Hook führt `schema-upgrade` einmal aus, bevor die neuen Pods starten, und nur, wenn Helms `lookup` zeigt, dass alle Server gestoppt sind. Renderings durch Argo CD, Flux und `helm template` verweigern den Hook; verwenden Sie stattdessen den manuellen Job aus der README des Charts. Ein `helm rollback` auf eine Revision von Chart 1.0.x bringt den Server nicht zurück, weil 3.0.x die aktualisierte Datenbank verweigert: Stellen Sie stattdessen die Sicherung wieder her.
 
+Chart 1.2.0 setzt das Standard-Image ohne Schemaänderung auf Server 3.4.0, daher genügt von Chart 1.1.0 aus ein einfaches `helm upgrade`. Native Pods erhalten außerdem eine `preStop`-Pause (`native.preStopSleepSeconds`, Standard 5) und eine Beendigungsfrist von 70 Sekunden. Chart 1.3.0 setzt das Standard-Image auf Server 3.5.0, das das [Schema-Upgrade von 11 auf 12](#native-schema-upgrade-3-5) benötigt: Skalieren Sie den Server auf null, sichern Sie die Datenbank und führen Sie `helm upgrade` mit `native.schemaUpgrade.enabled=true` aus (oder den manuellen Job), skalieren Sie danach wieder hoch. Siehe die [Hinweise zu Chart 1.3.0 / Server 3.5.0](%%artifact.helmChartUpgradeUrl%%#chart-130--server-350-native) des Charts. Zurück zu Chart 1.2.0 geht es nur über diese Sicherung.
+
 ### Einen Chart-Release auswählen {#helm-chart-selection}
 
 Jeder Chart-Release hält das getestete Server-Image in der `appVersion` der `Chart.yaml` fest; Chart und Server haben unabhängige Versionsnummern. Die ausgewählte [kompatible Kombination](./compatibility.md#last-qualified-reproducible-tuple) verbindet Chart **%%artifact.helmChartVersion%%** mit Server **%%artifact.helmChartAppVersion%%** aus denselben Release-Metadaten wie Tabelle und Installationsbefehl. Der [Prüfbericht zu OCI/veröffentlichtem Paket](%%artifact.helmChartQualificationUrl%%) bestätigt diese Kombination, keine neue Kubernetes-Installation.

i18n/de/docusaurus-plugin-content-docs/current/polyglot/server.md

@@ -412,11 +412,11 @@ curl http://localhost:8080/api/cluster/info \
 
 Liefert Build-Identität, Fähigkeitsflags, Protokollmanifeste, Limits und
 Erkennungsdaten für den Namespace aus `X-Namespace` (oder dem Abfrageparameter
-`namespace`, sonst `default`). Gekürzte Ausgabe des Images 3.3.2:
+`namespace`, sonst `default`). Gekürzte Ausgabe des Images 3.5.0:
 
 ```json
 {
-  "version": "3.3.2",
+  "version": "3.5.0",
   "implementation": "rust",
   "development": false,
   "server_id": "2145ce2abb12",
@@ -457,6 +457,9 @@ Erkennungsdaten für den Namespace aus `X-Namespace` (oder dem Abfrageparameter
       "supported_workflow_task_commands": ["schedule_activity", "start_timer", "complete_workflow", "..."],
       "query_tasks": true,
       "workflow_updates": true,
+      "sticky_execution": { "supported": true, "...": "..." },
+      "sticky_history_suffix": { "supported": true, "version": 1 },
+      "activity_workflow_continuation": { "version": 1, "...": "..." },
       "...": "..."
     }
   },
@@ -482,11 +485,12 @@ Wichtige Feldhinweise für Client-Code:
 - Die Build-Version steht in `version`, nicht in `server_version`.
   `implementation` ist auf dem nativen Server `"rust"`.
 - Prüfen Sie `control_plane.version` und `worker_protocol.version`, bevor Sie die
-  API aufrufen. Der native Server 3.3.2 bedient Steuerungsebene `2` und Worker-Protokoll
+  API aufrufen. Der native Server 3.5.0 bedient Steuerungsebene `2` und Worker-Protokoll
   `1.20` und akzeptiert Worker-Anfragen mit jeder Protokollversion von `1.0` bis
   `1.20`.
 - Workflow-Aufgabenbefehle stehen unter
   `worker_protocol.server_capabilities.supported_workflow_task_commands`.
+- Seit 3.5.0 meldet `worker_protocol.server_capabilities` `sticky_execution` und `sticky_history_suffix`. Seit 3.4.0 meldet es `activity_workflow_continuation`, das ein Worker nur nach seinem eigenen Opt-in verwendet.
 - Ein auf `false` gesetztes Fähigkeitsflag benennt eine Funktion oder einen
   veröffentlichten Vertrag, den der native Server nicht bedient.
   `response_compression` ist leer, weil der native Server Antworten

i18n/de/source-hashes.json

@@ -28,7 +28,7 @@
   "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf",
   "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529",
   "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c",
-  "deployment.md": "52490cc5b048b880746326f1c441fff88398f564d2af6d0a92cc671d1d7ecaf7",
+  "deployment.md": "69d24711e8622c949f783f224d39932f9f2d217913558073ea25a7d5df318455",
   "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -91,7 +91,7 @@
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
   "polyglot/server-config-reference.md": "6c28075a3245c30d54e4d7578f63519e9ad1e407bd72bf47121e0d055e0f60fc",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "682aed5dfad3f48f76523993f6403f144fc5f4aa5659707396beeff2afc3c043",
+  "polyglot/server.md": "d4f4c0640b862d772b03990457a47950be08a05123d25f9b4d7432da0a034b70",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
   "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d",
   "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327",