panicked at 'unexpected event 59'

[HaoboGu]

Recently I encountered some runtime panics, the following is the log:

DEBUG on_data_length_update conn_handle=4 max_rx_octets=251 max_rx_time_us=2120 max_tx_octets=251 max_tx_time_us=2120
└─ nrf_softdevice::ble::gap::on_evt @ /Users/haobogu/.cargo/git/checkouts/nrf-softdevice-03ef4aef10e777e4/d5f023b/nrf-softdevice/src/fmt.rs:125 
DEBUG on_conn_param_update conn_handle=4 conn_sup_timeout=100 max_conn_interval=12 min_conn_interval=12 slave_latency=4
└─ nrf_softdevice::ble::gap::on_evt @ /Users/haobogu/.cargo/git/checkouts/nrf-softdevice-03ef4aef10e777e4/d5f023b/nrf-softdevice/src/fmt.rs:125 
ERROR panicked at 'unexpected event 59'
└─ nrf_softdevice::ble::gatt_client::att_mtu_exchange::{async_fn#0}::{closure#2} @ /Users/haobogu/.cargo/git/checkouts/nrf-softdevice-03ef4aef10e777e4/d5f023b/nrf-softdevice/src/fmt.rs:101 
ERROR panicked at /Users/haobogu/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/defmt-0.3.10/src/lib.rs:380:5:
explicit panic
└─ panic_probe::print_defmt::print @ /Users/haobogu/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/panic-probe-0.3.2/src/lib.rs:104 

It seems that there's a timeout when exchanging mtu:

nrf-softdevice/nrf-softdevice/src/ble/gatt_client.rs

Lines 589 to 608 in b53991e

	portal(conn_handle)
	.wait_once(|ble_evt| unsafe {
	match (*ble_evt).header.evt_id as u32 {
	raw::BLE_GAP_EVTS_BLE_GAP_EVT_DISCONNECTED => return Err(MtuExchangeError::Disconnected),
	raw::BLE_GATTC_EVTS_BLE_GATTC_EVT_EXCHANGE_MTU_RSP => {
	let gattc_evt = match check_status(ble_evt) {
	Ok(evt) => evt,
	Err(e) => return Err(e.into()),
	};
	let params = get_union_field(ble_evt, &gattc_evt.params.exchange_mtu_rsp);
	let mtu = params.server_rx_mtu;
	debug!("att mtu exchange: got mtu {:?}", mtu);
	conn.with_state(|state| state.att_mtu = mtu);
	Ok(())
	}
	e => panic!("unexpected event {}", e),
	}
	})
	.await

Is there any methods to avoid this panic or manually handle it?

[peter9477]

I believe this may be another example of the sort of problem I reported in a PR comment at #195 (comment)

We're about to start on some ANCS work which will probably force us to sort this out, though if anyone else has already improved the design in ways that address this it would be nice. Will look into that soon...

Reviewing the discover_services(), discover_characteristics(), and att_mtu_exchange(), I see each is written with a particular design in mind:

1. initiate an operation
2. handle the expected result of the operation
3. handle one exceptional case that everyone knows could occur (disconnect)
4. panic on any other exceptional case, in essence pretending nothing else could every go wrong

I believe #4 is the fundamental design flaw that exists. I think the design must allow for any of the possible events that could occur, and rather than panicking it must provide some way to bubble that event to other listeners, or something similar.