🐛 Multi ReadCharacteristic Value Race Condition on iOS

[andrewcharnley]

Prerequisites

• I checked the documentation and FAQ without finding a solution
• I checked to make sure that this issue has not already been filed

Expected Behavior

On iOS with 3.50 calls to readcharacteristic sometimes return the value for a different characteristic. While I haven't looked at the Java I suspect it's returning the Promise early and the next iteration is then conflicting. If readCharacteristic should support parallel async calls then the internal code must have an issue, but here I am sequencing them.

It's only occurring on iOS and only sometimes but this will be down to timing/race. I've also tried the Promise patch file from the other PR. I didn't see this or have it reported by users on 3.2.* and will roll back.

Here's the code I have which will occasionally return the value for a different characteristic. I've verified with a user when it occurs the value returned for one characteristic is actually the value for another.

      for (const { name, uuid } of service.characteristics
         .filter(({ read }) => read)) {
              const {value} = await device.readCharacteristicForService(service.uuid, uuid);
              const output = ret.characteristics[name];
              const buffer = decodeBase64(value);
              output.bufferLength = buffer.length;
              addDebug(`Read ${name} of length ${buffer.length}`);
        
...

Current Behavior

It's unreliable.

Library version

3.5.0

Device

iOS

Environment info

N/A

Steps to reproduce

N/A

Formatted code sample or link to a repository

No

Relevant log output

N/A

Additional information

No response

[andrewcharnley]

Reverted back to 3.2.1 and users report all is well again. Something between then and 3.5.0 changed things.

[andrewcharnley]

Sadly this has returned. I don't have much to go on other than a hidden app log from a user. It shows the 'status' characteristic being of length 2 but the only characteristic with that length is 'control'.

The characterstics get read in a sequence using code...

` for (const { uuid:serviceUUID, characteristics } of services) {
for (const { name, uuid } of characteristics
.filter(({ read }) => read)) {

          const {value} = await device.readCharacteristicForService(serviceUUID, uuid);
          const output = ret.characteristics[name];
          const buffer = decodeBase64(value);
          output.bufferLength = buffer.length;
          addDebug(`Read ${name} of length ${buffer.length}`);

`

(see the addDebug which is what the user has reported).

So if 'status' read was correct then 'control' would be next.

I think the underlying device.discoverAllServicesAndCharacteristics() code is broken in so far that when I request a UUID it's internal mapping is then requesting another.

As before this hasn't been seen on Android.

[andrewcharnley]

I'm dumping the response to the debug window and will report back once user has updated.

[andrewcharnley]

Sticking this here for comparison to what the user gets so I don't lose it.

[andrewcharnley]

I have another user this time iPhone 16 + ios 26.3 with the same. After looking at the debugging info it's definitely that the data is being swapped between characteristics. Whether this is a bug in ios or the blx layer is undetermined but it seems more likely to be the latter.

Another user resolved it by turning bluetooth off, restarting phone and turning bluetooth back on. It doesn't occur often otherwise I'd have a lot of complaints.

[andrewcharnley]

This confirms it - you can see that the data for status(1525) characteristic is swapped with control(1526) characteristic.

The three comma delimited values are from

   addDebug(`${response.serviceID}, ${response.id}, ${response.serviceUUID.substr(4,4)}`);

The .serviceID and .id I guess are internal mapping values and may be useful. It may be nothing that the values are much higher.

[andrewcharnley]

I have found a documentation & validation error which might explain the behaviour, maybe.

According to the documentation .readCharacteristicForService() takes the service UUID as it's first argument.

Ref - https://dotintent.github.io/react-native-ble-plx/#devicereadcharacteristicforservice

and https://github.com/dotintent/react-native-ble-plx/wiki/Characteristic-Reading

However the code shows this is the serviceID (int) not the serviceUUID (string).

https://github.com/dotintent/react-native-ble-plx/blob/master/src/BleModule.js#L531

Because there's no validation the string gets converted into an int (which won't match) and works it's way up, but somehow it's still working. Somewhere there must be code to ignore the invalid service int and check all services for the specified characteristic uuid.

I have no idea if this is related to my problem but will switch to using .readCharacteristicForDevice() instead and see how it goes.

Also the user has reported they didn't need to restart the device, simply toggling bluetooth on/off was enough to 'fix' the problem.

[andrewcharnley]

I can confirm this hasn't resolved it.

I also have a new user with the problem but with two iPhones both running iOS 26.3 and the same App one connects and the other doesn't. This is starting to look more like an iOS issue.

[andrewcharnley]

Now conversing with Apple over this.

https://developer.apple.com/forums/thread/817515?login=true&page=1#878293022

I still believe it's either:

1. A race issue with this library on iOS.
2. An issue with iOS CoreBluetooth.

Apple have suggested an interesting way to collect Bluetooth logs so I'm looking into this.