Right now if you write to LED Text to display a message on the LED display and the display is already busy, the request is ignored and there's an error returned by the micro:bit API call. But as far as the connected Bluetooth client is concerned, the write worked.
This specific issue may be dealt with in a different way (we may make the BLE write take priority and interrupt any current display animation) but it would be good if a general review of how API errors are handled in the context of Bluetooth operations was undertaken. Where possible and sensible, an error executing a BLE originated sequence of calls should result in an error code returned in the Bluetooth response PDU (if there is one).
Right now if you write to LED Text to display a message on the LED display and the display is already busy, the request is ignored and there's an error returned by the micro:bit API call. But as far as the connected Bluetooth client is concerned, the write worked.
This specific issue may be dealt with in a different way (we may make the BLE write take priority and interrupt any current display animation) but it would be good if a general review of how API errors are handled in the context of Bluetooth operations was undertaken. Where possible and sensible, an error executing a BLE originated sequence of calls should result in an error code returned in the Bluetooth response PDU (if there is one).