Breaking change on workflow id reuse policy

daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-architecture.md

@@ -98,7 +98,7 @@ Each workflow actor saves its state using the following keys in the configured a
 | `inbox-NNNNNN` | A workflow's inbox is effectively a FIFO queue of _messages_ that drive a workflow's execution. Example messages include workflow creation messages, activity task completion messages, etc. Each message is stored in its own key in the state store with the name `inbox-NNNNNN` where `NNNNNN` is a 6-digit number indicating the ordering of the messages. These state keys are removed once the corresponding messages are consumed by the workflow. |
 | `history-NNNNNN` | A workflow's history is an ordered list of events that represent a workflow's execution history. Each key in the history holds the data for a single history event. Like an append-only log, workflow history events are only added and never removed (except when a workflow performs a "continue as new" operation, which purges all history and restarts a workflow with a new input). |
 | `customStatus` | Contains a user-defined workflow status value. There is exactly one `customStatus` key for each workflow actor instance. |
-| `metadata` | Contains meta information about the workflow as a JSON blob and includes details such as the length of the inbox, the length of the history, and a 64-bit integer representing the workflow generation (for cases where the instance ID gets reused). The length information is used to determine which keys need to be read or written to when loading or saving workflow state updates. |
+| `metadata` | Contains meta information about the workflow as a JSON blob and includes details such as the length of the inbox, the length of the history, and a 64-bit integer representing the workflow generation. The length information is used to determine which keys need to be read or written to when loading or saving workflow state updates. |
 
 {{% alert title="Warning" color="warning" %}}
 Workflow actor state remains in the state store even after a workflow has completed.

daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-features-concepts.md

@@ -84,7 +84,7 @@ dapr workflow resume wf-12345 \
 
 Each workflow you define has a type name, and individual executions of a workflow require a unique _instance ID_. Workflow instance IDs can be generated by your app code, which is useful when workflows correspond to business entities like documents or jobs, or can be auto-generated UUIDs. A workflow's instance ID is useful for debugging and also for managing workflows using the [Workflow APIs]({{% ref workflow_api.md %}}).
 
-Only one workflow instance with a given ID can exist at any given time. However, if a workflow instance completes or fails, its ID can be reused by a new workflow instance. Note, however, that the new workflow instance effectively replaces the old one in the configured state store.
+Only one workflow instance with a given ID can exist at any given time. Workflow instance IDs cannot be reused. Once a workflow completes or fails, you must use a unique instance ID for any new workflow execution. This ensures the history of a completed workflow is never overwritten.
 
 ### Workflow replay
 

daprdocs/content/en/operations/support/breaking-changes-and-deprecations.md

@@ -70,6 +70,7 @@ After announcing a future breaking change, the change will happen in 2 releases
 | NATS Streaming PubSub Component                                                                                                                                                                                                                                                                             | 1.11.0                   | 1.13.0         |
 | Workflows API Alpha1 `/v1.0-alpha1/workflows` being deprecated in favor of Workflow Client                                                                                                                                                                                                                  | 1.15.0                   | 1.17.0         |
 | Migration of `http-max-request-size` flags/annotations to `max-body-size`. See [How-To: Handle larger body requests]({{% ref increase-request-size.md %}})                                                                                                                                                  | 1.14.0                   | 1.17.0         |
+| Removal of workflow instance ID reuse policy. Workflow instance IDs can no longer be reused once a workflow completes or fails. This prevents the history of a completed workflow from being overwritten. Users must use a unique instance ID for each new workflow execution.                                 | 1.18.0                   | 1.18.0         |
 
 ## Related links