你好，目前我这边又出现了同样的情况：
设备client1 先连接上，然后在心跳间隔周期内，快速进行断开重启，client1 会进行重新连接。
此时会发生client1是会发生挤下线的行为，
整体的事件顺序是这样： connect1 → disconnect1 → connect2，
现象场景： client1 重新连接挤号行为，emqx会推送 一个 disconnect1 和 一个 connect2 事件，按照逻辑，应该是先生成 disconnect1 事件，再生成 connect2 事件，那么 disconnect1 事件的disconnected_at时间戳，是要小于 connect2 事件的 connected_at时间戳（这里不管最终推送抵达的先后顺序，只关心disconnected_at 和 connected_at 2个时间戳）。
出现的问题是： disconnect1 事件的 disconnected_at 时间戳 大于 connect2 事件的 connected_at 时间戳，预期肯定是小于的，毕竟是先产生disconnect1 再产生connect2；同时我也抓取了日志，确定disconnect1 的 connected_at 是和 connect1 的 connected_at 对得上的
目前我们有采用上下线的时间戳来保障设备的在线离线状态的准确性
期望：1.希望官方能帮忙定位下这个问题；2.有没有一些方案规避这个问题，不影响我的业务逻辑
补充下日志: 分别是 connect1 、disconnect1 、connect2
2026-02-27 16:29:50.194 [MQTT Call: sub_connect_172.31.0.1:18081_3] INFO c.s.i.mqtt.callback.ConnectCallback - ConnectEventStr:{"ipaddress":"219.133.191.30","expiry_interval":7200000,"clean_start":false,"sockport":1883,"connected_at":1772180990194,"proto_ver":4,"proto_name":"MQTT","clientid":"*****","username":"*****","ts":1772180990194,"protocol":"mqtt","keepalive":60}
2026-02-27 16:43:03.593 [MQTT Call: sub_disconnect_172.31.0.1:18081_3] INFO c.s.i.m.callback.DisconnectCallback - DisconnectEventStr:{"ipaddress":"219.133.191.30","disconnected_at":1772181783592,"sockport":1883,"connected_at":1772180990194,"proto_ver":4,"proto_name":"MQTT","clientid":"*****","username":"*****","ts":1772181783592,"protocol":"mqtt","reason":"takenover"}
2026-02-27 16:43:03.593 [MQTT Call: sub_connect_192.168.144.1:18081_4] INFO c.s.i.mqtt.callback.ConnectCallback - ConnectEventStr:{"ipaddress":"219.133.191.30","expiry_interval":7200000,"clean_start":false,"sockport":1883,"connected_at":1772181783591,"proto_ver":4,"proto_name":"MQTT","clientid":"*****","username":"*****","ts":1772181783591,"protocol":"mqtt","keepalive":60}