Aias00 opened a new issue, #7918: URL: https://github.com/apache/shenyu/issues/7918
### Behavior and reproduction At `fda742c48e7f553c9964cf74b36732326d0fde00`, two accepted CONNECT packets with the same clientId can leave both channels active. If the old channel later disconnects, cleanup removes the replacement connection's session because it looks up session ownership only by clientId. Executed with the real Connect handler, Disconnect.cleanChannel, repositories and two Netty EmbeddedChannels: 1. Connect old channel with clientId same-id and Clean Session true; consume its accepted CONNACK. 2. Connect a second channel with the same clientId and Clean Session true; consume its accepted CONNACK. 3. Observe both channels still active and the repository holding the replacement's session. 4. Run the old channel's normal cleanup routine. 5. Observe SessionRepository.get(same-id) becomes null while the replacement channel remains active. No network broker or mocks were used for the connect/repository/cleanup behavior. Test channels were closed and their messages released afterward. ### Location and cause - [Connect registers a channel without evicting another owner of the clientId](https://github.com/apache/shenyu/blob/fda742c48e7f553c9964cf74b36732326d0fde00/shenyu-protocol/shenyu-protocol-mqtt/src/main/java/org/apache/shenyu/protocol/mqtt/Connect.java#L87) - [ChannelRepository maps channel to clientId, with no active owner index](https://github.com/apache/shenyu/blob/fda742c48e7f553c9964cf74b36732326d0fde00/shenyu-protocol/shenyu-protocol-mqtt/src/main/java/org/apache/shenyu/protocol/mqtt/repositories/ChannelRepository.java#L31) - [Cleanup removes the session currently found by clientId](https://github.com/apache/shenyu/blob/fda742c48e7f553c9964cf74b36732326d0fde00/shenyu-protocol/shenyu-protocol-mqtt/src/main/java/org/apache/shenyu/protocol/mqtt/Disconnect.java#L62) The server must disconnect the existing connection when accepting a new connection for the same client identity. Cleanup also needs an ownership check/fence so a stale channel cannot erase the replacement's session. ### Impact / suggested repair Reconnects can leave simultaneous active connections and then lose the active connection's session/subscription bookkeeping when the stale connection exits. Add an atomic clientId-to-active-channel ownership transition, close the replaced connection, and fence its cleanup against the new owner. Cover clean and persistent sessions, graceful and abrupt old-channel closure, and repeated reconnects. Medium severity, high confidence from executed message handlers. Current issue/PR searches found no specific client takeover report; this is separate from wildcard matching, retained-message handling and Last Will publication itself. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
