"ble_gap_terminate" Occasionally Returns Unexpected HCI Error

[therealergo]

With my application (on an ESP32), in some cases I have to call "ble_gap_terminate" from within the event callback of "ble_gap_adv_start", for the event "BLE_GAP_EVENT_CONNECT". The NimBLE documentation suggests that making this kind of call from a callback should work without issue. In some cases this call will return "BLE_HS_ENOTCONN," which is expected e.g. if the connection had immediately failed right after the connection event was raised. However, if I force this code path to run repeatedly, then about 1 out of every 2000 times it runs I instead get the HCI error "BLE_ERR_UNK_CONN_ID". This error probably isn't supposed to leak out like this in normal use.

Looking at the source for "ble_gap_terminate", it appears that the check for "BLE_HS_ENOTCONN" is implemented by a call to "ble_hs_conn_find," which is run before the HCI command is transmitted. There are several concurrency-related reasons why that check might pass, even though the later HCI command will fail. It'd probably be better to specifically check for the "BLE_ERR_UNK_CONN_ID" HCI error, and return "BLE_HS_ENOTCONN" in that case.

[sjanc]

I could be due to connection being already terminated (or failed to establish) but host hasn't processed event yet and thus controller rejected HCI command from host

I suppose grabbing HCI trace would shed some light on this