Known Issues in EMQX 5.9
e5.9.0
| Since version | Issue | Workaround | Status |
|---|---|---|---|
| 5.0.0 | Route and Session Registry Can Become Inconsistent in Clusters 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: - 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. - 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. - 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. These fixes are landed in newer release lines but will not be backported to 5.9. See emqx/emqx PRs #17076, #17257, and #17522. | - | Upgrade to 5.10.4+, 6.1.2+, or 6.2.1+ |
| 5.0.0 | Node Crash if Linux monotonic clock steps backward In certain virtual Linux environments, the operating system is unable to keep the clocks monotonic, which may cause Erlang VM to exit with the message OS monotonic time stepped backwards!. | For such environments, you may set the +c flag to false in etc/vm.args. | |
| 5.3.0 | Limitation in SAML-Based SSO EMQX Dashboard supports Single Sign-On based on the Security Assertion Markup Language (SAML) 2.0 standard and integrates with Okta and OneLogin as identity providers. However, the SAML-based SSO currently does not support a certificate signature verification mechanism and is incompatible with Azure Entra ID due to its complexity. | - | |
| 5.1.0 | Replicant nodes may hang on startup when new core nodes are added to the cluster 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. In Kubernetes deployments, this led to the controller repeatedly restarting replicant pods due to failing readiness probes. 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 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 |