Update en_US/changes/known-issues-6.0.md

Co-authored-by: Copilot <[email protected]>

Author: Meggielqk

en_US/changes/known-issues-6.0.md

@@ -4,6 +4,6 @@
 
 | Since version | Issue                                                        | Workaround                                                   | Status |
 | ------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------ |
-| 6.0.0         | **Cannot perform rolling upgrade from cluster running 5.x to 6.0.0 when older bridges are in the configuration**<br />Clusters that have started running from older EMQX versions that contain the now deprecated `bridges` configuration root will fail to sync their configuration to the new 6.0 nodes, because the latter have dropped for such roots and thus fail to start the corresponding Connectors, Actions and Sources. | Starting from 6.0.1, an RPC call is made to the older node to upgrade the configuration to convert `bridges` into `connectors`, `sources,` and `actions`, facilitating rolling upgrades with less manual intervention.<br />Alternatively, each affected bridge can be updated via HTTP API or CLI to induce a configuration update (e.g., change the description), which will also upgrade the persisted `cluster.hocon` file.<br />The following Connector/Sources/Actions might still require manual changes before attempting a rolling upgrade:<br /> - GCP PubSub Consumer<br /> - Kafka Consumer<br />If there are any such sources in the configuration that still contain the `topic_mapping` field, the field must be removed from config and then one "Source + Rule" pair must be created for each entry. |        |
+| 6.0.0         | **Cannot perform rolling upgrade from cluster running 5.x to 6.0.0 when older bridges are in the configuration**<br />Clusters that have started running from older EMQX versions that contain the now deprecated `bridges` configuration root will fail to sync their configuration to the new 6.0 nodes, because the latter have dropped for such roots and thus fail to start the corresponding Connectors, Actions and Sources. | Starting from 6.0.1, an RPC call is made to the older node to upgrade the configuration to convert `bridges` into `connectors`, `sources` and `actions`, facilitating rolling upgrades with less manual intervention.<br />Alternatively, each affected bridge can be updated via HTTP API or CLI to induce a configuration update (e.g., change the description), which will also upgrade the persisted `cluster.hocon` file.<br />The following Connector/Sources/Actions might still require manual changes before attempting a rolling upgrade:<br /> - GCP PubSub Consumer<br /> - Kafka Consumer<br />If there are any such sources in the configuration that still contain the `topic_mapping` field, the field must be removed from config and then one "Source + Rule" pair must be created for each entry. |        |
 | 5.1.0         | **Replicant nodes may hang on startup when new core nodes are added to the cluster**<br />During cluster changes that involve adding new core nodes, the newly added cores may occasionally fail to start replication-related processes required by replicant nodes. This, in turn, caused upgraded or newly added replicant nodes to hang during startup.<br />In Kubernetes deployments, this led to the controller repeatedly restarting replicant pods due to failing readiness probes.<br />This problem typically occurs during upgrade rollouts, for example, when expanding an existing 2-core + 2-replicant cluster by adding two new core nodes and two new replicants running a newer EMQX version. | If one or more replicant nodes hang during startup after being (re)deployed, consider forcefully restarting the newly added core nodes one at a time until the replicants unblock and complete startup. | Fixed in 6.0.1 |