# Known Issues in EMQX 5.10

## 5.10.2

| Since version | Issue                                                        | Workaround                                                   | Status                    |
| ------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------- |
| 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 5.10.3, 6.0.1 |
| 5.7.0         | **Cluster Link garbage collection may remove active routes**<br />When multiple independent Cluster Links are configured and some links remain down for relatively long periods, the garbage collection process may mistakenly remove active routes from the internal routing table. This can cause affected Cluster Links to forward only a subset of messages or stop forwarding messages entirely. | -                                                        | Fixed in 5.10.3, 6.1.0 |
## 5.10.0

| Since version | Issue                                                        | Workaround                                                   | Status            |
| ------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ----------------- |
| 5.0.0         | **Route and Session Registry Can Become Inconsistent in Clusters**<br />Several related issues can leave stale or missing entries in the route table and the global session (channel) registry after cluster events such as a network partition heal, an abrupt node shutdown, or an RPC timeout during cleanup. Concrete symptoms:<br />- Routes for subscribers on a replicant node may not fully resynchronize after a network partition heals, so some subscriptions silently stop receiving messages until the affected node restarts.<br />- Channels owned by replicant nodes can be dropped from the global registry after a partition heal, leading to incorrect session takeover (a reconnecting client may not displace its old session) and misleading client counts in the Dashboard.<br />- Global session registry rows can leak indefinitely when a session's owner process dies without a clean unregister (for example after a brief network split that prevents the unregister from replicating, or when a core's consensus check times out during down-event cleanup) and the same client ID never reconnects. Over time these dead rows accumulate.<br />These fixes are landed in later patch releases of 5.10 and in newer release lines. See emqx/emqx PRs [#17076](https://github.com/emqx/emqx/pull/17076), [#17257](https://github.com/emqx/emqx/pull/17257), and [#17522](https://github.com/emqx/emqx/pull/17522). | -                                                            | Upgrade to 5.10.4+, 6.1.2+, or 6.2.1+ |