Jacob Trueb

sounds like you failed pairing ```dart /// Retrieves the value of the characteristic Future read() async { var request = protos.ReadCharacteristicRequest.create() ..remoteId = deviceId.toString() ..characteristicUuid = uuid.toString() ..serviceUuid = serviceUuid.toString();...

Seems like these calls could have a built in timeout or a chained timeout: https://stackoverflow.com/questions/52672137/await-future-for-a-specific-time You can't cancel a future, so accumulating permanently pending futures looks like a memory leak...

> I have built a timeout on future, but i think it is not the best solution because: if i set the duration to low, user doesn't has enough time...

Related: https://stackoverflow.com/questions/27836416/corebluetooth-pairing-feedback-callback/54644299#54644299 This question recommends attempting a write and checking for an error like 'Authentication is insufficient'. In my experience, there are other mechanisms for initiating pairing through the iOS...

That sounds like you are causing the blocking behavior. Aside from changing the control flow to use .then, I think it is just up to you to write better client...

Yes, the existing code requires a deeper dive than a pleasant try-catch on an await call. I was mostly pointing out that if you inspect the code that actually runs...

It seems that the intent of the change is to allow undocumented static assertions within traits, where this is easier to implement. There are probably corner cases that I cannot...

You might want to break out the features and choose reqwest, hyper, awc, and tls based on features instead of using this PR.

I have an example file that does not parse with decompress or decompress-fast, but if gunzip'ed parses just fine. I have tried compressing with native (macos) gzip and flate2, and...

I discounted the schema as the actual problem, but it is spot on. At some point in the gunzip'ing and gzip'ing, the file became corrupted. I have a similar loading...