Apply suggestions from code review

Co-authored-by: Niall Glynn <[email protected]>

Author: johndowns

articles/service-bus-messaging/service-bus-async-messaging.md

@@ -52,7 +52,7 @@ Other components within Azure can occasionally have service issues. For example,
 ### Service Bus failure on a single subsystem
 With any application, circumstances can cause an internal component of Service Bus to become inconsistent. When Service Bus detects this, it collects data from the application to aid in diagnosing what happened. Once the data is collected, the application is restarted in an attempt to return it to a consistent state. This process happens fairly quickly, and results in an entity appearing to be unavailable for up to a few minutes, though typical down times are much shorter.
 
-In these cases, the client application generates a timeout exception or a messaging exception. Service Bus contains a mitigation for this issue in the form of automated client retry logic. Once the retry period is exhausted and the message is not delivered, you might use [geo-replication](./service-bus-geo-replication.md), [geo-disaster recovery](./service-bus-geo-dr.md), or another approach to [switch to a different namespace](./service-bus-outages-disasters.md).
+In these cases, the client application generates a timeout exception or a messaging exception. Service Bus contains a mitigation for this issue in the form of automated client retry logic. Once the retry period is exhausted and the message is not delivered, you can use [geo-replication](./service-bus-geo-replication.md), [geo-disaster recovery](./service-bus-geo-dr.md), or another approach to [switch to a different namespace](./service-bus-outages-disasters.md).
 
 ## Next steps
 Now that you've learned the basics of asynchronous messaging in Service Bus, read more details about [Reliability in Azure Service Bus][/azure/reliability/reliability-service-bus?toc=/azure/service-bus-messaging/TOC.json].

articles/service-bus-messaging/service-bus-geo-dr.md

@@ -124,7 +124,7 @@ Once the failover is initiated -
 1. Pull messages from the former primary namespace once it's available again. After that, use that namespace for regular messaging outside of your Geo-Disaster Recovery setup, or delete the old primary namespace.
 
 > [!NOTE]
-> Only *fail-forward* semantics are supported. When you initiate a failover with geo-disaster recovery, you can optionally re-pair with a new namespace after failover completes. Failing back to the previous primary replica is not supported. These semantics might be different to other data stores you're used to, like Microsoft SQL Server clusters.
+> Only *fail-forward* semantics are supported. When you initiate a failover with geo-disaster recovery, you can re-pair with a new namespace after failover completes. You can't fail back to the previous primary replica. These semantics might be different to other data stores you're used to, like Microsoft SQL Server clusters.
 
 You can automate failover either with monitoring systems, or with custom-built monitoring solutions. However, such automation takes extra planning and work, which is out of the scope of this article.
 

articles/service-bus-messaging/service-bus-outages-disasters.md

@@ -10,13 +10,13 @@ ms.date: 04/29/2024
 Mission-critical applications must operate continuously, even in the presence of unplanned outages or disasters. Resilience against disastrous outages of data processing resources is a requirement for many enterprises and in some cases even required by industry regulations.
 
 > [!NOTE]
-> The Service Bus Geo-Disaster Recovery and Geo-Replication features are designed to make it easier to recover from a disaster of this magnitude, or to abandon a failed Azure region for good and without having to change your application configurations. For more information about these features and how to enable reliability and resiliency in Azure Service Bus, see [Reliability in Azure Service Bus](/azure/reliability/reliability-service-bus?toc=/azure/service-bus-messaging/TOC.json).
+> Service Bus Geo‑Disaster Recovery and Geo‑Replication help you recover from large‑scale disasters or permanently abandon a failed Azure region without requiring changes to your application configuration. For more information about these features and how to enable reliability and resiliency in Azure Service Bus, see [Reliability in Azure Service Bus](/azure/reliability/reliability-service-bus?toc=/azure/service-bus-messaging/TOC.json).
 
 If you can't use Geo-Disaster Recovery or Geo-Replication to meet your requirements, you can deploy multiple Service Bus namespaces. This article describes techniques you can use to protect applications against a potential service outage or disaster by using multiple namespaces.
 
 ## Replication types
 
-To achieve resilience against disasters with the Service Bus Standard tier, you can use **active** or  **passive** replication. For each approach, if a given queue or topic must remain accessible in the presence of a datacenter outage, you can create it in both namespaces. Both entities can have the same name. For example, a primary queue can be reached under **contosoPrimary.servicebus.windows.net/myQueue**, while its secondary counterpart can be reached under **contosoSecondary.servicebus.windows.net/myQueue**.
+To achieve resilience against disasters with the Service Bus Standard tier, you can use **active** or  **passive** replication. If a queue or topic must remain available during a datacenter outage, create the same entity in both namespaces. The entities can share the same name because they exist in separate namespaces. For example, you can reach a primary queue under **contosoPrimary.servicebus.windows.net/myQueue**, while you can reach its secondary counterpart under **contosoSecondary.servicebus.windows.net/myQueue**.
 
 >[!NOTE]
 > The **active replication** and **passive replication** setup are general purpose concepts and not specific features of Service Bus.