Bluetooth connect timeout after full flashing micro:bit whilst connected

[microbit-grace]

Reproduction steps

1. Flash micro:bit with data-collection-program.hex (can flashed/acccessed via https://createai.microbit.org/).
2. Visit https://microbit-connection.pages.dev/.
3. Connect to micro:bit via "Web Bluetooth" connection type.
4. Whilst connected, flash a program from https://python.microbit.org/v/3.
5. Return to https://microbit-connection.pages.dev/, you should see the status as "Disconnected".
6. Flash micro:bit with data-collection-program.hex again.
7. Refresh https://microbit-connection.pages.dev/ page.
8. Attempt to connect to micro:bit via "Web Bluetooth" connection type.

Connect will fail with the following error:

The fix for it appears to be just a matter of waiting and not attempting to connect for a while. The issue seems to somehow fix itself.

[microbit-robert]

This seems to be due to powering off the micro:bit or having some other connection failure during the connection process. I can reproduce this by powering off the micro:bit just after the connection starts.

This is the point of failure https://github.com/microbit-foundation/microbit-connection/blob/main/lib/bluetooth-device-wrapper.ts#L336.

this.device.gatt?.connected is synchronous and quick to respond. The device is still connected at this point, so we continue into getPrimaryService. This is async, and on Windows when tested locally, takes about 2 seconds to return a value, and longer to fail. Essentially, all is going well, but if the connection fails while waiting for a response from getPrimaryService, we eventually throw the model number error.

The failure appears to be harmless. The next connection attempt can succeed.

It is not clear why we don't capture this error -> https://github.com/microbit-foundation/microbit-connection/blob/main/lib/bluetooth-device-wrapper.ts#L432-L434. If we did, we'd end up with a more sensible log: "Failed to establish a connection!".

[microbit-grace]

Reproduction steps

These steps don't seem to reliably reproduce the issue as I originally thought.

Also tried the powering off repro steps as described by Rob: I do get an error, though not exactly the same error logs. I seem to either get a Error: Bluetooth GATT server connect error timeout or the Could not read model number error, but this could be a timing issue in terms of when the powering off occurs

[microbit-robert]

We updated the error logging to give us a better stack trace for these errors: #45

We think some "model number" errors are expected. Closing for now.