Bug Native exceptions on Android when aborting a UnityWebRequest

We have a pretty complex problem that does not always reproduce.
It also only started happening recently as we moved to 2018.4.26

In some cases, when 2 requests are "in flight", it seems that when aborting one of them, an exception is thrown (native Android one), and then the responses from the 2 requests are somehow "mixed".

To illustrate what i just said:

- Request A sent - it's response is supposed to be " { 1234 } " (just an example...)
- Request B sent - it's response is supposed to be " { 5678 } "

- Request A is aborted
- Request B's response would be something like " { 678 { 1234 }" and JSON parsing fails since it's not a valid JSON format

Both requests are using the DownloadHandlerBuffer object, not sure how it is possible that the responses are somehow "mixed".

Also, when the request is aborted and the bug is reproduced , we see the following exception in Logcat:

UnityWebRequest: abort threw an exception Attempt to read from field 'int com.android.okhttp.okio.Segment.limit' on a null object reference

We tried to make sure the calls are done serially, e.g: one after the other, that did fix the "mixing" issue, but the 2nd request now fails with an "Unknown error". Also we saw this error in logcat in this case:

UnityWebRequest: errorCallback with error=java.lang.ArrayIndexOutOfBoundsException: size=25 offset=491 byteCount=1 url=xxxxxxxxxx
java.lang.ArrayIndexOutOfBoundsException: size=25 offset=491 byteCount=1

@Aurimas-Cernius maybe u are familiar with a similar bug? i am not sure i understand why it happens in this particular case. I believe it's related to the fact that the first request is aborted, and this is the only place in our project we are calling Abort on any request.

Also, i saw that in 2018.4.26 there was a change to the underlying native implementation on Android, there's now a dedicated abort() method that is called in native code (Java) that didn't exist before we made the upgrade (we upgraded from 2018.4.0).

Any words of advice would help

 

Both requests use the DownloadHandlerBuffer under the hood - is there a chance somehow the buffers are "shared" between different requests? e.g: how can 1 request's response get mixed with another one?