[management] Refactor/management/updchannel

[crn4]

Describe your changes

Replaced write lock with read lock for peerChannels map access where only read operations are performed

Issue ticket number and link

Checklist

• Is it a bug fix
• Is a typo/documentation fix
• Is a feature enhancement
• It is a refactor
• Created tests that fail without the change (if possible)
• Extended the README / documentation, if necessary

[CLAassistant]

All committers have signed the CLA.

[Copilot]

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (3)

management/server/updatechannel.go:45

• Ensure that using RLock in SendUpdate is safe because this function must not perform any modifications on the peerChannels map. If a write operation is introduced in the future, a write lock should be used.

p.channelsMux.RLock()

management/server/updatechannel.go:144

• Verify that the use of RLock in GetAllConnectedPeers is appropriate as this function should only read from the peerChannels map. Any future changes requiring modifications to the map would necessitate reverting to a write lock.

p.channelsMux.RLock()

management/server/updatechannel.go:166

• Confirm that HasChannel remains read-only when accessing the peerChannels map, ensuring that the read lock is sufficient. If the implementation changes to mutate the map, a write lock will be required.

p.channelsMux.RLock()

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud