Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

`okhttp3.internal.Util.closeQuietly` isn't that quite

See original GitHub issue

It seems that an issue with the underlying buffer / connection may lead to an Exception (or even Error!) thrown from close method of the response. An example:

    java.lang.AssertionError: java.io.EOFException
        at okio.Buffer.clear(Buffer.java:932)
        at okio.RealBufferedSource.close(RealBufferedSource.java:477)
        at okhttp3.internal.Util.closeQuietly(Util.java:139)

What surprised us is Util.closeQuietly in the stacktrace. Isn’t it supposed to catch such errors and e.g. log instead of re-throwing?

Issue Analytics

State:
Created 3 years ago
Reactions:1
Comments:8 (4 by maintainers)

Top GitHub Comments

2reactions

yschimkecommented, Jun 23, 2020

Yes, probably two questions to answer

Should closeQuietly throw RuntimeException or AssertionErrors?
Should okio ever turn a user input or end of stream into a non IOException?

https://twitter.com/bsideup/status/1273169998018752512

1reaction

swankjessecommented, Jun 23, 2020

This particular crash is caused by unsafe concurrent access to a Buffer. Perhaps one code path is calling close() while another code path is attempting to read? Okio streams are not safe for concurrent use, and calling close() while another thread is reading or writing is unsupported.

The word quietly in this context is intended to hide IOExceptions only. The AssertionError here is an invariant being violated, and I don’t think it makes sense to attempt to recover from unexpected crashes.