Name Workflow 2.20.2 as the fix for stranded stream messages

docs/failures-and-recovery.md

@@ -118,6 +118,7 @@ The successor replays workflow code from the start:
 - A signal wait (`await('name')`) that received and applied its signal is reused with the signal's value. The signal is not delivered again.
 - An update that was accepted, applied and completed before the failed step is recorded again at the same position. Replay runs the update handler from its recorded arguments, so the workflow's state matches. The update is not delivered again. A rejected update, and one the failure closed before it ran, are left out.
 - `outbox()->sendReference()` and `inbox()->receive()` in reused workflow code return the message the failed run sent or consumed. They don't send or consume it again. A replayed receive whose original call found nothing reads the stream again.
+- In Workflow 2.20.2 and later, inbound stream messages still pending on the failed run move to the successor. Workflow 2.20.1 and earlier left them on the failed run, so the successor never received them ([workflow#1013](https://github.com/durable-workflow/workflow/issues/1013)).
 - If an activity failure ended the run, the failed activity call is scheduled as a new activity execution, using the retry policy in the workflow code. Its attempts start again.
 - If the run failed in workflow code or on a structural limit, the successor resumes at the step the workflow code never reached.
 - Everything after the failed step runs as it would in a new run.

docs/features/continue-as-new.md

@@ -165,8 +165,8 @@ class PollingWorkflow extends Workflow
 
 For long-lived human-input or assistant loops, prefer the first-class
 `$this->inbox()` / `$this->outbox()` [Message Streams](./message-streams.md)
-facade. The cursor position moves to the continued run, while consumed messages
-remain on the original run as history evidence. In Workflow releases through
-2.20.1, stream messages still pending at continue-as-new stay on the closed run
-([workflow#1018](https://github.com/durable-workflow/workflow/issues/1018)); see
-[Message Streams](./message-streams.md#continue-as-new).
+facade. Pending stream messages and the cursor position move to the continued
+run, while consumed messages remain on the original run as history evidence.
+Workflow 2.20.1 and earlier left pending stream messages on the closed run
+([workflow#1018](https://github.com/durable-workflow/workflow/issues/1018),
+fixed in 2.20.2); see [Message Streams](./message-streams.md#continue-as-new).

docs/features/message-streams.md

@@ -129,13 +129,14 @@ store separately from durable message ordering.
 
 ## Continue-As-New
 
-Message streams are instance-first. When a workflow continues as new, the
-cursor position carries forward to the continued run, and consumed messages
-remain attached to the original run as historical evidence. In Workflow
-releases through 2.20.1, messages still pending when the run continues as new
-stay on the closed run, and the continued run never receives them
-([workflow#1018](https://github.com/durable-workflow/workflow/issues/1018)).
-Until a release fixes this, receive pending messages before you call
+Message streams are instance-first. When a workflow continues as new, pending
+inbound messages move to the continued run, the cursor position carries
+forward, and consumed messages remain attached to the original run as
+historical evidence. Workflow 2.20.1 and earlier moved only the cursor:
+messages still pending when the run continued as new stayed on the closed run,
+and the continued run never received them
+([workflow#1018](https://github.com/durable-workflow/workflow/issues/1018),
+fixed in 2.20.2). On those releases, receive pending messages before you call
 `continueAsNew()`, or send input that must survive the handoff as a
 [signal](./signals.md): accepted signals that the run has not applied move to
 the continued run.

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

@@ -115,6 +115,7 @@ Der Nachfolger spielt den Workflow-Code von Anfang an erneut ab:
 - Eine Signalwarteoperation (`await('name')`), die ihr Signal empfangen und angewendet hat, wird mit dem Wert des Signals wiederverwendet. Das Signal wird nicht erneut zugestellt.
 - Ein Update, das vor dem fehlgeschlagenen Schritt angenommen, angewendet und abgeschlossen wurde, wird an derselben Stelle erneut aufgezeichnet. Das Replay führt den Update-Handler mit den aufgezeichneten Argumenten aus, sodass der Zustand des Workflows übereinstimmt. Das Update wird nicht erneut zugestellt. Ein abgelehntes Update und eines, das der Fehler vor seiner Ausführung geschlossen hat, werden ausgelassen.
 - `outbox()->sendReference()` und `inbox()->receive()` in wiederverwendetem Workflow-Code geben die Nachricht zurück, die der fehlgeschlagene Lauf gesendet oder konsumiert hat. Sie senden oder konsumieren sie nicht erneut. Ein Receive im Replay, dessen ursprünglicher Aufruf nichts gefunden hat, liest den Stream erneut.
+- In Workflow 2.20.2 und später gehen eingehende Stream-Nachrichten, die auf dem fehlgeschlagenen Lauf noch ausstehen, auf den Nachfolger über. Workflow 2.20.1 und früher ließen sie auf dem fehlgeschlagenen Lauf, sodass der Nachfolger sie nie erhielt ([workflow#1013](https://github.com/durable-workflow/workflow/issues/1013)).
 - Wenn ein Aktivitätsfehler den Lauf beendet hat, wird der fehlgeschlagene Aktivitätsaufruf als neue Aktivitätsausführung mit der Wiederholungsrichtlinie aus dem Workflow-Code eingeplant. Seine Versuche beginnen von vorn.
 - Wenn der Lauf im Workflow-Code oder an einem strukturellen Limit fehlgeschlagen ist, setzt der Nachfolger an dem Schritt fort, den der Workflow-Code nie erreicht hat.
 - Alles nach dem fehlgeschlagenen Schritt läuft wie in einem neuen Lauf.

i18n/de/docusaurus-plugin-content-docs/current/features/continue-as-new.md

@@ -178,10 +178,9 @@ class PollingWorkflow extends Workflow
 
 Für langlebige Schleifen mit menschlichen Eingaben oder Assistenten bevorzugen
 Sie die vollwertige Fassade `$this->inbox()` / `$this->outbox()` für
-[Nachrichtenströme](./message-streams.md). Die Cursor-Position geht auf den
-fortgesetzten Lauf über, während verbrauchte Nachrichten als Historiennachweis
-auf dem ursprünglichen Lauf bleiben. In Workflow-Releases bis einschließlich
-2.20.1 bleiben Stromnachrichten, die beim Continue-as-new noch ausstehen, auf dem
-geschlossenen Lauf
-([workflow#1018](https://github.com/durable-workflow/workflow/issues/1018)); siehe
-[Nachrichtenströme](./message-streams.md#continue-as-new).
+[Nachrichtenströme](./message-streams.md). Ausstehende Stromnachrichten und die
+Cursor-Position gehen auf den fortgesetzten Lauf über, während verbrauchte
+Nachrichten als Historiennachweis auf dem ursprünglichen Lauf bleiben. Workflow
+2.20.1 und früher ließen ausstehende Stromnachrichten auf dem geschlossenen Lauf
+([workflow#1018](https://github.com/durable-workflow/workflow/issues/1018),
+behoben in 2.20.2); siehe [Nachrichtenströme](./message-streams.md#continue-as-new).

i18n/de/docusaurus-plugin-content-docs/current/features/message-streams.md

@@ -137,14 +137,16 @@ Payload-Speicher getrennt von der dauerhaften Nachrichtenreihenfolge prüfen.
 
 ## Continue-as-new {#continue-as-new}
 
-Nachrichtenströme orientieren sich an Instanzen. Bei Continue-as-new geht die
-Cursor-Position auf den fortgesetzten Lauf über, und verbrauchte Nachrichten
-bleiben als historische Nachweise am ursprünglichen Lauf. In Workflow-Releases
-bis einschließlich 2.20.1 bleiben Nachrichten, die beim Continue-as-new noch
-ausstehen, am geschlossenen Lauf, und der fortgesetzte Lauf erhält sie nie
-([workflow#1018](https://github.com/durable-workflow/workflow/issues/1018)).
-Bis ein Release dies behebt, empfangen Sie ausstehende Nachrichten, bevor Sie
-`continueAsNew()` aufrufen, oder senden Sie Eingaben, die die Übergabe
+Nachrichtenströme orientieren sich an Instanzen. Bei Continue-as-new gehen
+ausstehende eingehende Nachrichten auf den fortgesetzten Lauf über, die
+Cursor-Position wird übernommen, und verbrauchte Nachrichten bleiben als
+historische Nachweise am ursprünglichen Lauf. Workflow 2.20.1 und früher
+übertrugen nur den Cursor: Nachrichten, die beim Continue-as-new noch
+ausstanden, blieben am geschlossenen Lauf, und der fortgesetzte Lauf erhielt sie
+nie
+([workflow#1018](https://github.com/durable-workflow/workflow/issues/1018),
+behoben in 2.20.2). Empfangen Sie in diesen Releases ausstehende Nachrichten,
+bevor Sie `continueAsNew()` aufrufen, oder senden Sie Eingaben, die die Übergabe
 überstehen müssen, als [Signal](./signals.md): Angenommene Signale, die der Lauf
 noch nicht angewendet hat, gehen auf den fortgesetzten Lauf über.
 

i18n/de/source-hashes.json

@@ -29,19 +29,19 @@
   "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529",
   "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c",
   "deployment.md": "503230f8cc2378726d32557cc17bc4c44f527082c382c39a6b24ab1913476877",
-  "failures-and-recovery.md": "352aef2a7cdb60b84ba6d9fb265b5ab8e4d53d5d027ed2683a0fe1604da6895b",
+  "failures-and-recovery.md": "e92644a4808a0712f905ebdf649b2de51f6b65958107881e18427e5d1fa56ed2",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "c678fc7a0c9b11f0e1bee295aff259de9803219c0aa6769fb801622799e7deb1",
   "features/child-workflows.md": "57016591fb8816aed7b077e204f1c80f9c6a8dff7501bc00a141c41a4607306b",
   "features/concurrency.md": "a7a3eb2274f7b14faf722494569b7663c07ab48afdf2e9225e58914b84cacbb4",
   "features/condition-waits.md": "451261eda990c9591a0db69839d872184b5c64da6b537a582133095b8d4b599e",
-  "features/continue-as-new.md": "9757751fe96226bd4499c3548f446ef7eb4e0d61ef4001064aa4ee66738731d9",
+  "features/continue-as-new.md": "50c79f317155e052a3f2f37d198a71bdfc496a454905293f40cf09d73138f25b",
   "features/events.md": "c466df05908748489226a3d1410c9203cf6f2986a4bb7539db1c5f82715abc7b",
   "features/external-payload-storage.md": "acc312fa2f50a43c96e1d235439124d28a7048f0bf3abac34319467fcbf7e898",
   "features/heartbeats.md": "e3d84178788dff92954e08d08f006def0a991a481f99301facbda8c6ca21a7a0",
   "features/local-activities.md": "05fca8f2104d8f4e7bd8b48040f5615f18d0ee2795922fb65c56f8d3d70ed204",
   "features/memo.md": "621aa630e37fbef6f84d761c92f99dc3fe8756879008c659cbad0600eb14fd5d",
-  "features/message-streams.md": "b04de795e9856015438ecc0659001d386295e428c45b6ab79a2d7311fcfae924",
+  "features/message-streams.md": "b30c7629d3fb9d20f27c4bcf0551457d65ac44a541b119312a2cde31aba48354",
   "features/queries.md": "c66dd9542a062edd8158a46cebc9f1bf926aaf3599dca4a3122bd9860df6e2a2",
   "features/sagas.md": "8dae955491a54bcbf545ce6972928df59f3885e00f98bf3a57b14dad98f89161",
   "features/schedules.md": "717b9115ca62a69a3a1ea65f1bec68a0aebe0d5e6d2421df297bb129c597a523",

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

@@ -119,6 +119,7 @@ La sucesora vuelve a reproducir el código del workflow desde el principio:
 - Una espera de señal (`await('name')`) que recibió y aplicó su señal se reutiliza con el valor de la señal. La señal no se vuelve a entregar.
 - Un update que se aceptó, se aplicó y se completó antes del paso fallido se vuelve a registrar en la misma posición. El replay ejecuta el handler del update con sus argumentos registrados, así que el estado del workflow coincide. El update no se vuelve a entregar. Un update rechazado, y uno que el fallo cerró antes de ejecutarse, se omiten.
 - `outbox()->sendReference()` e `inbox()->receive()` en el código de workflow reutilizado devuelven el mensaje que la ejecución fallida envió o consumió. No lo vuelven a enviar ni a consumir. Un receive en replay cuya llamada original no encontró nada vuelve a leer el stream.
+- En Workflow 2.20.2 y versiones posteriores, los mensajes entrantes del stream que siguen pendientes en la ejecución fallida pasan a la sucesora. Workflow 2.20.1 y versiones anteriores los dejaban en la ejecución fallida, así que la sucesora nunca los recibía ([workflow#1013](https://github.com/durable-workflow/workflow/issues/1013)).
 - Si un fallo de actividad terminó la ejecución, la llamada de actividad fallida se programa como una ejecución de actividad nueva, con la política de reintentos del código del workflow. Sus intentos empiezan de nuevo.
 - Si la ejecución falló en el código del workflow o por un límite estructural, la sucesora se reanuda en el paso que el código del workflow nunca alcanzó.
 - Todo lo que sigue al paso fallido se ejecuta como en una ejecución nueva.

i18n/es/docusaurus-plugin-content-docs/current/features/continue-as-new.md

@@ -152,4 +152,4 @@ class PollingWorkflow extends Workflow
 }
 ```
 
-Para bucles prolongados de intervención humana o asistentes, prefiere la fachada de primera clase `$this->inbox()` / `$this->outbox()` de [Flujos de mensajes](./message-streams.md). El cursor pasa a la nueva ejecución; los mensajes consumidos permanecen en la original como evidencia histórica. En las versiones de Workflow hasta la 2.20.1, los mensajes del flujo aún pendientes al continuar como nueva ejecución permanecen en la ejecución cerrada ([workflow#1018](https://github.com/durable-workflow/workflow/issues/1018)); consulta [Flujos de mensajes](./message-streams.md#continue-as-new).
+Para bucles prolongados de intervención humana o asistentes, prefiere la fachada de primera clase `$this->inbox()` / `$this->outbox()` de [Flujos de mensajes](./message-streams.md). Los mensajes pendientes del flujo y el cursor pasan a la nueva ejecución; los mensajes consumidos permanecen en la original como evidencia histórica. Workflow 2.20.1 y versiones anteriores dejaban los mensajes pendientes del flujo en la ejecución cerrada ([workflow#1018](https://github.com/durable-workflow/workflow/issues/1018), corregido en 2.20.2); consulta [Flujos de mensajes](./message-streams.md#continue-as-new).

i18n/es/docusaurus-plugin-content-docs/current/features/message-streams.md

@@ -112,7 +112,7 @@ Esto mantiene pequeño el historial y permite validar el almacén por separado d
 
 ## Continuar como nueva ejecución {#continue-as-new}
 
-Los flujos se centran en la instancia. Al continuar como nueva ejecución, el cursor pasa a la sucesora y los mensajes consumidos siguen vinculados a la original como evidencia histórica. En las versiones de Workflow hasta la 2.20.1, los mensajes aún pendientes cuando la ejecución continúa como nueva permanecen en la ejecución cerrada y la sucesora nunca los recibe ([workflow#1018](https://github.com/durable-workflow/workflow/issues/1018)). Hasta que una versión lo corrija, recibe los mensajes pendientes antes de llamar a `continueAsNew()`, o envía como [señal](./signals.md) la entrada que deba sobrevivir al traspaso: las señales aceptadas que la ejecución aún no haya aplicado pasan a la sucesora.
+Los flujos se centran en la instancia. Al continuar como nueva ejecución, los mensajes entrantes pendientes pasan a la sucesora, el cursor avanza con ella y los mensajes consumidos siguen vinculados a la original como evidencia histórica. Workflow 2.20.1 y versiones anteriores solo trasladaban el cursor: los mensajes aún pendientes cuando la ejecución continuaba como nueva permanecían en la ejecución cerrada y la sucesora nunca los recibía ([workflow#1018](https://github.com/durable-workflow/workflow/issues/1018), corregido en 2.20.2). En esas versiones, recibe los mensajes pendientes antes de llamar a `continueAsNew()`, o envía como [señal](./signals.md) la entrada que deba sobrevivir al traspaso: las señales aceptadas que la ejecución aún no haya aplicado pasan a la sucesora.
 
 Un workflow prolongado puede desprenderse del historial conservando la misma ruta pública de mensajes:
 

i18n/es/source-hashes.json

@@ -29,19 +29,19 @@
   "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529",
   "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c",
   "deployment.md": "503230f8cc2378726d32557cc17bc4c44f527082c382c39a6b24ab1913476877",
-  "failures-and-recovery.md": "352aef2a7cdb60b84ba6d9fb265b5ab8e4d53d5d027ed2683a0fe1604da6895b",
+  "failures-and-recovery.md": "e92644a4808a0712f905ebdf649b2de51f6b65958107881e18427e5d1fa56ed2",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "c678fc7a0c9b11f0e1bee295aff259de9803219c0aa6769fb801622799e7deb1",
   "features/child-workflows.md": "57016591fb8816aed7b077e204f1c80f9c6a8dff7501bc00a141c41a4607306b",
   "features/concurrency.md": "a7a3eb2274f7b14faf722494569b7663c07ab48afdf2e9225e58914b84cacbb4",
   "features/condition-waits.md": "451261eda990c9591a0db69839d872184b5c64da6b537a582133095b8d4b599e",
-  "features/continue-as-new.md": "9757751fe96226bd4499c3548f446ef7eb4e0d61ef4001064aa4ee66738731d9",
+  "features/continue-as-new.md": "50c79f317155e052a3f2f37d198a71bdfc496a454905293f40cf09d73138f25b",
   "features/events.md": "c466df05908748489226a3d1410c9203cf6f2986a4bb7539db1c5f82715abc7b",
   "features/external-payload-storage.md": "acc312fa2f50a43c96e1d235439124d28a7048f0bf3abac34319467fcbf7e898",
   "features/heartbeats.md": "e3d84178788dff92954e08d08f006def0a991a481f99301facbda8c6ca21a7a0",
   "features/local-activities.md": "05fca8f2104d8f4e7bd8b48040f5615f18d0ee2795922fb65c56f8d3d70ed204",
   "features/memo.md": "621aa630e37fbef6f84d761c92f99dc3fe8756879008c659cbad0600eb14fd5d",
-  "features/message-streams.md": "b04de795e9856015438ecc0659001d386295e428c45b6ab79a2d7311fcfae924",
+  "features/message-streams.md": "b30c7629d3fb9d20f27c4bcf0551457d65ac44a541b119312a2cde31aba48354",
   "features/queries.md": "c66dd9542a062edd8158a46cebc9f1bf926aaf3599dca4a3122bd9860df6e2a2",
   "features/sagas.md": "8dae955491a54bcbf545ce6972928df59f3885e00f98bf3a57b14dad98f89161",
   "features/schedules.md": "717b9115ca62a69a3a1ea65f1bec68a0aebe0d5e6d2421df297bb129c597a523",

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

@@ -123,6 +123,7 @@ Le successeur rejoue le code du workflow depuis le début :
 - Une attente de signal (`await('name')`) qui a reçu et appliqué son signal est réutilisée avec la valeur du signal. Le signal n’est pas remis à nouveau.
 - Un update accepté, appliqué et terminé avant l’étape échouée est enregistré de nouveau à la même position. Le replay exécute le handler de l’update avec ses arguments enregistrés, si bien que l’état du workflow correspond. L’update n’est pas livré de nouveau. Un update rejeté, et un update que l’échec a fermé avant son exécution, sont laissés de côté.
 - `outbox()->sendReference()` et `inbox()->receive()` dans le code de workflow réutilisé renvoient le message que l’exécution échouée a envoyé ou consommé. Ils ne l’envoient ni ne le consomment de nouveau. Un receive rejoué dont l’appel d’origine n’a rien trouvé relit le stream.
+- Dans Workflow 2.20.2 et les versions ultérieures, les messages entrants du stream encore en attente sur l’exécution échouée passent au successeur. Workflow 2.20.1 et les versions antérieures les laissaient sur l’exécution échouée, si bien que le successeur ne les recevait jamais ([workflow#1013](https://github.com/durable-workflow/workflow/issues/1013)).
 - Si un échec d’activité a mis fin à l’exécution, l’appel d’activité échoué est planifié comme une nouvelle exécution d’activité, avec la politique de nouvelles tentatives du code du workflow. Ses tentatives repartent de zéro.
 - Si l’exécution a échoué dans le code du workflow ou sur une limite structurelle, le successeur reprend à l’étape que le code du workflow n’a jamais atteinte.
 - Tout ce qui suit l’étape échouée s’exécute comme dans une nouvelle exécution.