There were a couple of rare error states that could happen if timeouts happened in the middle of a multi part listen, or if writeAndAssemble received more data than expected that were not being handled correctly (could fail to throw an error, could leave the bluetooth stack in a weird state where late operations would fail).
Proposed Solution:
Throw a new .tooMuchData error for writeAndAssemble if the data overflows the expected length
If the wait inside a synchronous background listen (listen, writeAndListen, writeAndAssemble) times out, always treat it as an error, even if there has also been some successful receipt of data.
Testing Completed and Required:
Verified the behaviour of all the failure modes for write and assemble inside another app. The error edge cases for this are strange enough that it is a little tricky to test them in the real world, writeAndAssemble can be tested artificially by lying about the expected amount of data, but its not clear how to verify the correct behaviour of listen and writeAndListen without hardware that causes the behaviour. The changes are relatively low risk though, given the the changes are identical to writeAndListen, which CAN be tested.
For #240, #242
Summary of Problem:
There were a couple of rare error states that could happen if timeouts happened in the middle of a multi part listen, or if writeAndAssemble received more data than expected that were not being handled correctly (could fail to throw an error, could leave the bluetooth stack in a weird state where late operations would fail).
Proposed Solution:
.tooMuchDataerror for writeAndAssemble if the data overflows the expected lengthTesting Completed and Required:
Verified the behaviour of all the failure modes for write and assemble inside another app. The error edge cases for this are strange enough that it is a little tricky to test them in the real world, writeAndAssemble can be tested artificially by lying about the expected amount of data, but its not clear how to verify the correct behaviour of listen and writeAndListen without hardware that causes the behaviour. The changes are relatively low risk though, given the the changes are identical to writeAndListen, which CAN be tested.