Can sd_ble_gap_data_length_update return NRF_ERROR_BUSY if I only use it in response to a BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST?

[Elias]

I'm not totally clear from the SDK documentation on when I can expect NRF_ERROR_BUSY from sd_ble_gap_data_length_update(). Would it happen in the case where both sides attempted to do sd_ble_gap_data_length_update() at nearly the same time? If I see a sd_ble_gap_data_length_update(), would I expect to soon receive a BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST? If I only do sd_ble_gap_data_length_update() in response to BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST, can I expect to never see NRF_ERROR_BUSY?

I am using s132 v5.1.0.

[Edvin]

As I understand it, it only returns NRF_ERROR_BUSY if you already called it once before, without the process having finished. Do you see that it returns NRF_ERROR_BUSY at some point?

Best regards,

Edvin

[Elias]

Ah, it makes sense that if I send sd_ble_gap_data_length_update() twice and the peer didn't process the first request, then the second call returns "busy". I have never seen it, I was just wondering if it was worth it for me to add special handling. It sounds like it is not, since my application never initiates the request.