Select Server 3.7.0 and chart 1.5.0; MySQL JSON schema upgrade

docs/deployment.md

@@ -268,6 +268,62 @@ 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.7.0 {#native-schema-upgrade-3-7}
+
+Server 3.7.0 stores MySQL JSON documents as exact text, so doubles keep every
+digit. Only MySQL changes: its native schema moves from 12 to 13, and its 75
+`json` columns in 36 tables become `LONGTEXT` (`utf8mb4_bin`) with an enforced
+`json_valid` check, one `ALTER TABLE` per table. Documents already stored keep
+MySQL's earlier rendering. A 3.7.0 Server started on MySQL schema 12 refuses
+with `native_schema_upgrade_required`.
+
+MariaDB and PostgreSQL stay at schema 12 and SQLite at 11, so a 3.5.0 or 3.6.0
+database on them runs on 3.7.0 as it is: change only `DW_SERVER_IMAGE` and
+follow the upgrade order above. Rolling back to 3.6.0 is an image change. From
+3.4.x or earlier, every database also needs the
+[3.5.0 schema step](#native-schema-upgrade-3-5); run it with the 3.7.0 image,
+whose `schema-upgrade` applies the earlier steps too.
+
+On MySQL the Server is down for the whole upgrade. Measured on MySQL 8.0 with
+2 CPUs and the default buffer pool, it takes about 2 minutes per million
+history rows. 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.6.0 on MySQL.
+3. Change `DW_SERVER_IMAGE` to the 3.7.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
+   ```
+
+   On MySQL it prints the schema versions before and after, for example
+   `"from_schema_version":12,"schema_version":13,"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.7.0`) and
+   worker registration.
+
+An interrupted upgrade resumes table by table when you run `schema-upgrade`
+again. Rolling back to 3.6.0 on MySQL needs the backup: a 3.6.0 Server refuses
+the upgraded database with `native_schema_newer_than_binary`. The worker
+protocol stays at `1.20` and the control plane at version `2`.
+
+Server 3.7.0 also changes native redrive (see the
+[3.7.0 release](https://github.com/durable-workflow/server/releases/tag/3.7.0)):
+memos and search attributes set at start carry to the successor, and
+`describe` reports `actions.can_redrive` and `actions.redrive_blocked_reason`.
+
 ### 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
@@ -678,6 +734,14 @@ Chart 1.4.0 moves the default image to Server 3.6.0 with no schema change, so
 a plain `helm upgrade` from chart 1.3.0 is enough, and going back to 1.3.0 is an
 image change. See the chart's
 [Chart 1.4.0 / Server 3.6.0 notes](%%artifact.helmChartUpgradeUrl%%#chart-140--server-360-native).
+Chart 1.5.0 moves the default image to Server 3.7.0. On MySQL it needs the
+[schema upgrade from 12 to 13](#native-schema-upgrade-3-7): 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.
+Going back to chart 1.4.0 on MySQL means restoring that backup. On MariaDB and
+PostgreSQL a plain `helm upgrade` is enough, and going back is an image change.
+See the chart's
+[Chart 1.5.0 / Server 3.7.0 notes](%%artifact.helmChartUpgradeUrl%%#chart-150--server-370-native).
 
 ### Choosing a chart release {#helm-chart-selection}
 

docs/failures-and-recovery.md

@@ -255,7 +255,7 @@ Workflow releases before 2.18.0 accept a narrower set of runs. Every step before
 
 Releases before 2.19.0 ignore `reused_recorded_at` on reused signal, memo and search-attribute steps. After a Workflow 2.19.0 or later successor reuses those steps, keep 2.19.0 or later workers, or confirm that no such history can replay, before you roll back. In embedded mode, Workflow 2.19.0 replays, imports and resumes a 2.20.0 successor that reused an update or a chained signal wait the same way 2.20.0 does ([qualification receipt](https://github.com/durable-workflow/workflow/issues/864#issuecomment-6617902412)).
 
-Redrive in the native Server still applies the rules from before 2.18.0. Native Server support for the current rules is tracked in [server#980](https://github.com/durable-workflow/server/issues/980).
+From 3.7.0, native Server redrive carries memos and search attributes set at start to the successor, and `describe()` reports `can_redrive` and `redrive_blocked_reason` under `actions`. Otherwise it still applies the rules from before 2.18.0. Native Server support for the remaining rules is tracked in [server#980](https://github.com/durable-workflow/server/issues/980).
 
 ## Service Entry Refusal and Recovery {#service-entry-recovery}
 

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

@@ -195,6 +195,37 @@ 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.7.0 {#native-schema-upgrade-3-7}
+
+Server 3.7.0 speichert JSON-Dokumente in MySQL als exakten Text, sodass Gleitkommazahlen (Doubles) jede Ziffer behalten. Nur MySQL ändert sich: Sein natives Schema wechselt von 12 auf 13, und seine 75 `json`-Spalten in 36 Tabellen werden zu `LONGTEXT` (`utf8mb4_bin`) mit einer erzwungenen `json_valid`-Prüfung, ein `ALTER TABLE` pro Tabelle. Bereits gespeicherte Dokumente behalten die bisherige Darstellung von MySQL. Ein Server 3.7.0, der auf MySQL-Schema 12 gestartet wird, verweigert den Start mit `native_schema_upgrade_required`.
+
+MariaDB und PostgreSQL bleiben bei Schema 12 und SQLite bei 11, daher läuft eine 3.5.0- oder 3.6.0-Datenbank auf diesen Systemen unverändert mit 3.7.0: Ändern Sie nur `DW_SERVER_IMAGE` und folgen Sie der oben beschriebenen Upgrade-Reihenfolge. Ein Rollback auf 3.6.0 ist dort nur ein Image-Wechsel. Von 3.4.x oder früher benötigt jede Datenbank zusätzlich den [Schemaschritt für 3.5.0](#native-schema-upgrade-3-5); führen Sie ihn mit dem 3.7.0-Image aus, dessen `schema-upgrade` auch die früheren Schritte anwendet.
+
+Auf MySQL ist der Server während des gesamten Upgrades nicht verfügbar. Gemessen auf MySQL 8.0 mit 2 CPUs und dem Standard-Pufferpool dauert es etwa 2 Minuten pro Million History-Zeilen. 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 auf MySQL der einzige Weg zurück zu 3.6.0.
+3. Ändern Sie `DW_SERVER_IMAGE` auf das 3.7.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
+   ```
+
+   Auf MySQL gibt der Befehl die Schemaversionen vorher und nachher aus, zum Beispiel `"from_schema_version":12,"schema_version":13,"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.7.0`) und die Worker-Registrierung.
+
+Ein unterbrochenes Upgrade wird Tabelle für Tabelle fortgesetzt, wenn Sie `schema-upgrade` erneut ausführen. Ein Rollback auf 3.6.0 erfordert auf MySQL die Sicherung: Ein 3.6.0-Server verweigert die aktualisierte Datenbank mit `native_schema_newer_than_binary`. Das Worker-Protokoll bleibt bei `1.20` und die Steuerungsebene bei Version `2`.
+
+Server 3.7.0 ändert außerdem den nativen Redrive (siehe die [Versionshinweise zu 3.7.0](https://github.com/durable-workflow/server/releases/tag/3.7.0)): Beim Start gesetzte Memos und Suchattribute werden auf den Nachfolger übernommen, und `describe` meldet `actions.can_redrive` und `actions.redrive_blocked_reason`.
+
 ### 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`.
@@ -469,7 +500,7 @@ 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. Chart 1.4.0 setzt das Standard-Image ohne Schemaänderung auf Server 3.6.0, daher genügt von Chart 1.3.0 aus ein einfaches `helm upgrade`, und ein Zurück zu 1.3.0 ist nur ein Image-Wechsel. Siehe die [Hinweise zu Chart 1.4.0 / Server 3.6.0](%%artifact.helmChartUpgradeUrl%%#chart-140--server-360-native) des Charts.
+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. Chart 1.4.0 setzt das Standard-Image ohne Schemaänderung auf Server 3.6.0, daher genügt von Chart 1.3.0 aus ein einfaches `helm upgrade`, und ein Zurück zu 1.3.0 ist nur ein Image-Wechsel. Siehe die [Hinweise zu Chart 1.4.0 / Server 3.6.0](%%artifact.helmChartUpgradeUrl%%#chart-140--server-360-native) des Charts. Chart 1.5.0 setzt das Standard-Image auf Server 3.7.0. Auf MySQL benötigt es das [Schema-Upgrade von 12 auf 13](#native-schema-upgrade-3-7): 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. Zurück zu Chart 1.4.0 geht es auf MySQL nur durch Wiederherstellen dieser Sicherung. Auf MariaDB und PostgreSQL genügt ein einfaches `helm upgrade`, und ein Zurück ist nur ein Image-Wechsel. Siehe die [Hinweise zu Chart 1.5.0 / Server 3.7.0](%%artifact.helmChartUpgradeUrl%%#chart-150--server-370-native) des Charts.
 
 ### Einen Chart-Release auswählen {#helm-chart-selection}
 

i18n/de/docusaurus-plugin-content-docs/current/failures-and-recovery.md

@@ -252,7 +252,7 @@ Workflow-Releases vor 2.18.0 nehmen weniger Läufe an. Jeder Schritt vor der feh
 
 Releases vor 2.19.0 ignorieren `reused_recorded_at` bei wiederverwendeten Signal-, Memo- und Suchattribut-Schritten. Nachdem ein Nachfolger aus Workflow 2.19.0 oder später diese Schritte wiederverwendet hat, behalten Sie Worker ab 2.19.0 bei oder stellen Sie vor einem Rollback sicher, dass keine solche Historie per Replay verarbeitet werden kann. Im Embedded-Modus verarbeitet Workflow 2.19.0 einen 2.20.0-Nachfolger, der ein Update oder eine verkettete Signalwarteoperation wiederverwendet hat, beim Replay, Import und Fortsetzen genauso wie 2.20.0 ([Qualifizierungsnachweis](https://github.com/durable-workflow/workflow/issues/864#issuecomment-6617902412)).
 
-Redrive im nativen Server wendet weiterhin die Regeln von vor 2.18.0 an. Die Unterstützung der aktuellen Regeln im nativen Server wird in [server#980](https://github.com/durable-workflow/server/issues/980) verfolgt.
+Ab 3.7.0 übernimmt Redrive im nativen Server beim Start gesetzte Memos und Suchattribute auf den Nachfolger, und `describe()` meldet `can_redrive` und `redrive_blocked_reason` unter `actions`. Ansonsten wendet er weiterhin die Regeln von vor 2.18.0 an. Die Unterstützung der übrigen Regeln im nativen Server wird in [server#980](https://github.com/durable-workflow/server/issues/980) verfolgt.
 
 ## Ablehnung am Einstieg im Servicemodus und Wiederherstellung {#service-entry-recovery}
 

i18n/de/source-hashes.json

@@ -28,8 +28,8 @@
   "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf",
   "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529",
   "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c",
-  "deployment.md": "4d3cb33a586dd83b643adbcd5b8c1ec7f27ef58369ac9dd0047563de626033df",
-  "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c",
+  "deployment.md": "6aa439b1ebfdc2affccaf6fe6fff7519776a4ffcad8d3cb5956b665e7c97257f",
+  "failures-and-recovery.md": "598b538e2bcb6a40a4f2d4c0c462705bab30ef96767144f6590c2cc93b68a98a",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
   "features/child-workflows.md": "57016591fb8816aed7b077e204f1c80f9c6a8dff7501bc00a141c41a4607306b",