Handle exceptions when resetting streams after writing to the network

[Ndiritu]

We added the isOneShot() check to ensure that rewindable request body streams are reset after writing them e.g. after request body is written to a logging interceptor. Previously, a logging interceptor would drain the request body stream causing the network call to have an empty body.

However, we didn't handle the failure scenarios of reset() according to the docs

This PR makes a best effort measure to prevent draining the request body by an interceptor before the final network request.

If a positive content length is available, we mark() the start of the stream with the entire stream's content length as the read limit.

If during the sink.writeAll() a new mark() is set causing the reset() to fail, we log the exception but don't fail the entire request.

We do not fail the entire request in case the first call to reset() happens during the network call.

closes microsoftgraph/msgraph-sdk-java#2245

Existing unit tests for the various stream scenarios still pass

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
75.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ihudedi]

Hi @Ndiritu
I saw another call to reset in this file and exception is thrown

Thanks,
Itay

[ihudedi]

Hi @Ndiritu
Did you see my last message.In retry method there is also reset that throw an exception.(retryCAEResponseIfRequired)
Thanks,
Itay

[Ndiritu]

Hi @Ndiritu Did you see my last message.In retry method there is also reset that throw an exception.(retryCAEResponseIfRequired) Thanks, Itay

@ihudedi the reset() called at this point is necessary since before retrying a request after getting a claims challenge we need to attempt to reset the body.

In this case, the error handling works as expected by bubbling up the exception to a developer's application.

[ihudedi]

Hi @Ndiritu
Thanks for the response.
Itay