Ideas for stress testing GPS via GadgetBridge

I can now reproduce the problem. It seems to independent of the bangle code as well as GPS reception. Forcing the problem to appear takes cutting of BT reception enough for a disconnect. The behaviour after is very similar to having a breakpoint in the loop of the dispatchThread in GB BtLEQueue and just leaving that hanging.
Normal execution looks like this:

nodomain.freeyourgadget.gadgetbridge.ser­vice.btle.BtLEQueue: about to add: 20:30:52: Transaction task: gps with 8 actions
nodomain.freeyourgadget.gadgetbridge.ser­vice.btle.BtLEQueue: About to run action: 1. März, 20:30: WriteAction on characteristic: 6e400002-b5a3-f393-e0a9-e50e24dcca9e
nodomain.freeyourgadget.gadgetbridge.ser­vice.btle.actions.WriteAction: writing to characteristic: 6e400002-b5a3-f393-e0a9-e50e24dcca9e: 0x10.....

After disconnecting bluetooth from the outside the GPS sending looks like this:

nodomain.freeyourgadget.gadgetbridge.ser­vice.btle.BtLEQueue: about to add: 19:51:53: Transaction task: gps with 7 actions

No WriteAction executing, just the next GPS update arriving and queuing up the next transaction task.

This is the only log line seeming relevant for this problem after the forced disconnect:

nodomain.freeyourgadget.gadgetbridge.ser­vice.devices.banglejs.BangleJSDeviceSupp­ort: Services discovered, but device state is already INITIALIZED for device: Device Bangle.js 773e, FF:3B:5A:19:77:3E, initialisiert, so ignoring

Save for BT disconnects the GPS from GB works really well now. @Gordon any idea what could be the problem here or where to search further? I'm a bit out of my depth regarding the BT LE stuff in GB.