Merge branch 'v1.15' into jobs-failure-policy

Author: acroca

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

@@ -31,7 +31,7 @@ When a workflow application starts up, it uses a workflow authoring SDK to send
 
 The workflow app executes the appropriate workflow code and then sends a gRPC request back to the sidecar with the execution results.
 
-<img src="/images/workflow-overview/workflow-engine-protocol.png" alt="Dapr Workflow Engine Protocol" />
+<img src="/images/workflow-overview/workflow-engine-protocol.png" width=500 alt="Dapr Workflow Engine Protocol" />
 
 All interactions happen over a single gRPC channel and are initiated by the application, which means the application doesn't need to open any inbound ports. The details of these interactions are internally handled by the language-specific Dapr Workflow authoring SDK.
 
@@ -91,7 +91,7 @@ Workflow actor state remains in the state store even after a workflow has comple
 
 The following diagram illustrates the typical lifecycle of a workflow actor.
 
-<img src="/images/workflow-overview/workflow-actor-flowchart.png" alt="Dapr Workflow Actor Flowchart"/>
+<img src="/images/workflow-overview/workflow-actor-flowchart.png" width=600 alt="Dapr Workflow Actor Flowchart"/>
 
 To summarize:
 
@@ -113,7 +113,7 @@ Each activity actor stores a single key into the state store:
 
 The following diagram illustrates the typical lifecycle of an activity actor.
 
-<img src="/images/workflow-overview/workflow-activity-actor-flowchart.png" alt="Workflow Activity Actor Flowchart"/>
+<img src="/images/workflow-overview/workflow-activity-actor-flowchart.png" width=600 alt="Workflow Activity Actor Flowchart"/>
 
 Activity actors are short-lived:
 

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

@@ -710,7 +710,7 @@ The monitor pattern is recurring process that typically:
 
 The following diagram provides a rough illustration of this pattern.
 
-<img src="/images/workflow-overview/workflow-monitor-pattern.png" width=600 alt="Diagram showing how the monitor pattern works"/>
+<img src="/images/workflow-overview/workflow-monitor-pattern.png" width=800 alt="Diagram showing how the monitor pattern works"/>
 
 Depending on the business needs, there may be a single monitor or there may be multiple monitors, one for each business entity (for example, a stock). Furthermore, the amount of time to sleep may need to change, depending on the circumstances. These requirements make using cron-based scheduling systems impractical.
 
@@ -953,7 +953,7 @@ Here's an example workflow for a purchase order involving a human:
 
 The following diagram illustrates this flow.
 
-<img src="/images/workflow-overview/workflow-human-interaction-pattern.png" width=600 alt="Diagram showing how the external system interaction pattern works with a human involved"/>
+<img src="/images/workflow-overview/workflow-human-interaction-pattern.png" width=800 alt="Diagram showing how the external system interaction pattern works with a human involved"/>
 
 The following example code shows how this pattern can be implemented using Dapr Workflow.
 

daprdocs/content/en/operations/resiliency/health-checks/app-health.md

@@ -22,6 +22,7 @@ App health checks are disabled by default. Once you enable app health checks, th
 - Unsubscribing from all pub/sub subscriptions
 - Stopping all input bindings
 - Short-circuiting all service-invocation requests, which terminate in the Dapr runtime and are not forwarded to the application
+- Unregistering Dapr Actor types, thereby causing Actor instances to migrate to a different replica if one is available
 
 These changes are meant to be temporary, and Dapr resumes normal operations once it detects that the application is responsive again.