Automation - Lock reads and writes from and to the ConfigDigest

[ferglor]

This data race was flagged up in #topic-data-races

The change here is adding a RWMutex to synchronize reads and writes from/to the ConfigDigest

[infiloop2]

why change this behaviour of only sending this message on config change and not on regular intervals?

[ferglor]

In the previous version of the code, we only sent the message when the config had changed:

chainlink/core/services/ocr2/plugins/ocr2keeper/evmregistry/v21/autotelemetry21/custom_telemetry.go

Line 71 in 1a2b7b6

e.sendNodeVersionMsg()

We need to lock the mutex before checking if the config has changed (the if statement); but because the sendNodeVersionMsg itself locks the Read lock on the mutex (because it gets called from other places, too), we can't execute the sendNodeVersionMsg function while the lock is held. And so, we're having to introduce this additional boolean that gets set to true when the config changes (previously, this is when we would have called sendNodeVersionMsg), and then reference that boolean outside the lock to determine if we should call sendNodeVersionMsg.

[infiloop2]

ah sorry had missed that e.sendNodeVersionMsg() was within the if statement before. There's a separate ticker which sends this message on regular intervals. Thanks for clarifying!

[infiloop2]

have a question about change of behaviour

[cl-sonarqube-production]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube