Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compression mishandles errors from underlying reader #37

Closed
tylerhawkes opened this issue Jan 30, 2019 · 2 comments
Closed

Compression mishandles errors from underlying reader #37

tylerhawkes opened this issue Jan 30, 2019 · 2 comments

Comments

@tylerhawkes
Copy link

I was using this library with a wrapped reader that can timeout to bound search time for a best compression algorithm. The reader returns an Error(ErrorKind::TimedOut) but brotli doesn't report it. I was looking at the code and it appears that https://github.com/dropbox/rust-brotli/blob/master/src/enc/mod.rs#L249 doesn't follow the contract of readers. The only error that is ignorable is an interrupt, but all errors are ignored and the stream happily closes even though it's only read like 2% of the data. Needless to say this makes it impossible to get the original data back when the BrotliCompress function returns Ok(_).

@danielrh
Copy link
Collaborator

Thanks for the bug report!
I've fixed it in version 3.1.8 with a test (just pushed)
Please let me know if the results are not what you'd expect.

Out of curiosity, which of your projects ran into this? Does the test you were doing pass now?

@tylerhawkes
Copy link
Author

Sorry about the delay. It appears to work as expected now.
The project is on an embedded platform where we're trying to losslessly compress artifacts for uploading and analysis later as much as possible to save on bandwidth. I get between the readers and writers and determine if the compression ratio is after some percentage of the reads is too high or taking too long and raise my own error to not let it go forever.
Brotli levels 10 and 11 take an incredibly long time between calls to read or to write. It would be nice to set a maximum time limit to write calls even if you wrote out a buffer of zero length because then I can cancel the operation with better time granularity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants