REFPLTV-3050: when there is no supported RCU models in configuration, no need to startPairing#183
Conversation
There was a problem hiding this comment.
Pull request overview
This PR aims to prevent BLE auto-pairing from starting when there are no configured/supported RCU models, which (per description) can otherwise lead to very high CPU utilization.
Changes:
- Add a guard in
startPairingAutoWithTimeout()to fail early when no RCU models are configured, settingm_lastErrorand logging a warning.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if (m_config->modelSettings().empty()) { | ||
| m_lastError = BleRcuError(BleRcuError::General, "No BLE RCU models configured"); | ||
| XLOGD_WARN("cannot start BLE auto pairing - no RCU models configured"); | ||
| return false; | ||
| } |
There was a problem hiding this comment.
This guard only checks whether modelSettings() is empty, but "no supported models" can also occur when the config contains only disabled models (see ConfigModelSettings::disabled() and the pairing state machine filtering out disabled models). In that case auto-pairing would still start with an empty supported-name list. Consider checking for at least one enabled model (e.g., any_of(models, !disabled)) and failing if none are enabled.
| if (m_config->modelSettings().empty()) { | ||
| m_lastError = BleRcuError(BleRcuError::General, "No BLE RCU models configured"); | ||
| XLOGD_WARN("cannot start BLE auto pairing - no RCU models configured"); | ||
| return false; | ||
| } | ||
|
|
||
| // check we're not currently pairing | ||
| if (m_pairingStateMachine.isRunning()) { | ||
| m_lastError = BleRcuError(BleRcuError::General, "currently performing pairing, cannot start new scan"); |
There was a problem hiding this comment.
This new early-return runs before the existing m_pairingStateMachine.isRunning() check. If auto-pair is requested while another pairing operation is already running, callers will now see a config error instead of the expected "busy" error. Consider keeping the busy check first (or otherwise ensuring the reported error prioritizes the in-progress operation).
| { | ||
| m_ignorePairingFailure = false; | ||
|
|
||
| if (m_config->modelSettings().empty()) { |
There was a problem hiding this comment.
ConfigSettings::modelSettings() returns the vector by value, so calling m_config->modelSettings().empty() copies the entire model list just to check emptiness. If this path can be hit repeatedly, consider caching the returned vector in a local variable (or adding a cheap hasModelSettings() / const-ref accessor on ConfigSettings).
Without this it is causing 95%+ CPU utilization