From adde78b24eaca895d35a5f7e021d1ccb0f46f580 Mon Sep 17 00:00:00 2001
From: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
Date: Thu, 30 May 2024 11:23:24 -0400
Subject: [PATCH] docs: Minor rewrites for clarity and style

---
 website/content/docs/release-notes/v0_16_0.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/content/docs/release-notes/v0_16_0.mdx b/website/content/docs/release-notes/v0_16_0.mdx
index 0761b10a58..6ff7e115bd 100644
--- a/website/content/docs/release-notes/v0_16_0.mdx
+++ b/website/content/docs/release-notes/v0_16_0.mdx
@@ -154,11 +154,11 @@ description: |-
     Controller dead lock with database connections stuck in <code>idle in transaction</code> state
     </td>
     <td style={{verticalAlign: 'middle'}}>
-    If you configured a controller to have the maximum number of open connections and it was under enough load from worker requests, the controller can get stuck. Once the controller consumed all of the database connections, it would leave them in an <code>idle in transaction</code> state. In extreme cases, this can cause Boundary clusters to become unresponsive.
+    If you configured a controller to have the maximum number of open connections and it was under enough load from worker requests, the controller could get stuck. Once the controller consumed all the database connections, it would leave them in an <code>idle in transaction</code> state. In extreme cases, this could cause Boundary clusters to become unresponsive.
     <br /><br />
-    The cause of this problem was due to a combination of issues including the lack of a request timeout for worker-to-controller GRPC requests, and the session repository attempting to use a separate database connection to retrieve a KMS wrapper, after already starting a database transaction.
+    The cause of this problem was due to a combination of issues. It included the lack of a request timeout for worker-to-controller GRPC requests. The session repository also attempted to use a separate database connection to retrieve a KMS wrapper after already starting a database transaction.
     <br /><br />
-    This issue is fixed in release 0.16.1 for Community and Enterprise editions. KMS operations now occur outside of the transaction, and a max request duration for GRPC requests is now set based on the cluster's listener configuration.
+    This issue is fixed in release 0.16.1 for the Community and Enterprise editions. KMS operations now occur outside of the transaction. Boundary also now sets a max request duration for GRPC requests based on the cluster's listener configuration.
     <br /><br />
     <a href="/boundary/tutorials/self-managed-deployment/upgrade-version">Upgrade to the latest version of Boundary</a>
     </td>