Expose a function to check if a `hyper::Error` is due to a `BodyWrite`
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 16.3k
- Forks
- 1.8k
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 14
Description
Is your feature request related to a problem? Please describe.
Originally reported in https://github.com/apache/arrow-rs/issues/5545, where they pointed me to ask some questions here. The gist of the problem is:
When using object_store, we've occasionally hit errors that point to this hyper error:
error writing a body to connection: Broken pipe (os error 32)
We would like to retry this specific error as it seems like something that should be retryable in our use case, but BodyWrite (and Body I suppose) both don't seem to expose any public functions to determine this at a glance.
Describe the solution you'd like
Add a is_body_write() (and maybe a is_body for feature parity with reads) function.
Describe alternatives you've considered
The current workaround we're doing is checking the Display output and checking if it matches the error message associated with BodyWrite - this works but it feels like a terrible workaround and is outright pointed out in the docs to not depend on this behaviour.
Additional context
If there's a better method or a reason this error reason isn't exposed, please let me know!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the public hyper::Error type and its BodyWrite and Body variants. Check how these error reasons are represented and exposed, then determine the scope of the requested is_body_write() predicate and whether a corresponding is_body() predicate is appropriate. Done means callers can identify BodyWrite errors without inspecting Display output.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend-api-design
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100