hyperium / hyperium/hyper

Expose a function to check if a `hyper::Error` is due to a `BodyWrite`

Open
#3,609 2 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

C-feature
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.