User Request
Type: bug
Target: Console Application
Submitted by: @aashu2006
Console Request ID: d163dd4e-8e1d-4150-b205-fc4602cfdd54
Description
What happened:
In pkg/api/handlers/websocket.go:155-166, the broadcast case acquires h.mu.RLock(), takes a local alias to h.userIndex[msg.userID] (sharing the underlying array), then releases RUnlock() before iterating the slice. DisconnectUser acquires RLock and reads the same userIndex while Hub.Run's unregister case holds Lock() and modifies the slice via append, potentially mutating the array that the broadcast iteration is reading.
What I expected:
The RLock should be held for the full iteration, or the slice contents (not just the header) should be copied before releasing the lock.
Steps to reproduce:
- Run with
-race flag
- Trigger concurrent broadcast and user disconnection
- Observe race detector flag on the shared slice array
This issue was automatically created from the KubeStellar Console.
User Request
Type: bug
Target: Console Application
Submitted by: @aashu2006
Console Request ID: d163dd4e-8e1d-4150-b205-fc4602cfdd54
Description
What happened:
In
pkg/api/handlers/websocket.go:155-166, the broadcast case acquiresh.mu.RLock(), takes a local alias toh.userIndex[msg.userID](sharing the underlying array), then releasesRUnlock()before iterating the slice.DisconnectUseracquiresRLockand reads the sameuserIndexwhileHub.Run's unregister case holdsLock()and modifies the slice via append, potentially mutating the array that the broadcast iteration is reading.What I expected:
The
RLockshould be held for the full iteration, or the slice contents (not just the header) should be copied before releasing the lock.Steps to reproduce:
-raceflagThis issue was automatically created from the KubeStellar Console.