Ignore delegate status on radio bridge disconnect

[microbit-robert]

When calling disconnect on MicrobitRadioBridgeConnection, this.serialSession?.dispose(true) is called which removes the serialdata listener once, giving this.addedListeners.serialdata a value of 0. Due to the boolean passed in, we disconnect the delegate, which causes a disconnected event to be picked up by the MicrobitRadioBridgeConnection delegateStatusListener. This in turn calls this.serialSession?.dispose() for the second time, removing the serialdata listener a second time. this.addedListeners.serialdata is now a truthy value of -1. This results in errors somewhere further in the process because a check using this.addedListeners.serialdata is now doing the wrong thing.

An alternative approach to fixing would be to ensure that this.addedListeners.serialdata cannot be set to a negative value.

This needs both approaches. ignoreDelegateStatus solves half a problem and makes sense to have, but unplugging the radio link device (after this disconnect) calls the same dispose code in the delegateStatusListener. Make the serial data listener a boolean. We don't respect the numbers of listeners at the moment anyway (i.e., removing one of many will still stop serial).

[microbit-grace]

Testing it out on CreateAI locally, it seems to have improved in that flashing the radio link micro:bit after a radio connection works ok, but flashing the remote micro:bit after radio connection still gives an error at times

[microbit-robert]

It's worse because there aren't logged errors - ignore me, need to reinstall the theme...

Flashing the remote micro:bit with the MakeCode program seems to work when run locally and skip flashing the remote micro:bit during the connection in CreateAI (before MakeCode). It seems to fail (most / all? of the time if you don't skip flashing).

After you've successfully or unsuccessfully flashed a MakeCode program to a device, reconnecting via radio bridge in CreateAI seems to fail (all?) the time.

Will test these scenarios on Windows shortly - inconclusive, see below.

Edit: I know one of my V2 devices has a dodgy USB connection. I am not the best person to be testing this without getting new devices.

[microbit-robert]

MacOS. With this version I can:

• connect via radio bridge
• go to MakeCode
• flash MakeCode program to remote micro:bit (may require unplug and replug)
• back to CreateAI to reconnect to record more data samples
• connect and flash remote micro:bit (may require unplug and replug)
• connect radio link micro:bit - fails with the following errors:

Event {"type":"WebUSB-error","message":"11/failed-to-execute-transferout-on-usbdevice-the-device-must-be-opened-first"}
Flashing failed: {"code":"reconnect-microbit"}

[microbit-robert]

When we start to flash the device in MakeCode, we call disconnectInputMicrobit, which reduces the value of this.addedListeners.serialdata by 1.

We then unplug the device (following the instructions) which causes a disconnected event to be picked up by the MicrobitRadioBridgeConnection delegateStatusListener. Following the same logic as the opening comment on this PR, this.addedListeners.serialdata is reduced by 1 again, making it -1 and a truthy value. Then everything breaks.

[cloudflare-workers-and-pages]

Deploying microbit-connection with    Cloudflare Pages

Latest commit:	6373a63
Status:	✅  Deploy successful!
Preview URL:	https://044f0503.microbit-connection.pages.dev
Branch Preview URL:	https://ignore-delegate.microbit-connection.pages.dev

View logs

[microbit-robert]

Changes need testing in Python Editor. Edit: I think this looks good.

[microbit-grace]

Tested this locally on CreateAI and the Python Editor and they both work well. LGTM!

[microbit-robert]

Closing in favour of #66