Allow to access response payload in `retry::Builder::{classify, classify_fn}`

[tnull]

I'm currently trying to replace our homebrewn retry logic with the retry::Builder shipped in reqwest v0.12.23.

Two things stand out to me that currently make it hard for us to switch or are a regression compared to what we had:

1. Not all types in the API are actually exposed. In particular ReqRep and Classify are currently inaccessible. Given the comment at the beginning of mod classify, this seems intentional, but is rather unfortunate.

2. More importantly: in our use case we need to access the payload of the raw response (in bytes), parse it (protobuf), and then based on the values there decide whether the error is retryable. It would therefore be great if the classify/classify_fn APIs would allow us to actually access the (error) response.

Thank you!

[seanmonstar]

Hey there! Yea, the API started conservative, hopefully with room to grow.

1. As use cases require, we can expose more things. I'd prefer to do so as we learn about them, instead of opportunistically, for now.
2. Ah, yea, the response body. We'd need to add some sort of classify_async_fn (naming hard). The harder part though, is that if you stream/consume the response body, what happens to the exposed body on Response after the retry says it's all good? Is it gone? Would we need some sort of replayable body, or a way for you to put it back?

[tnull]

• As use cases require, we can expose more things. I'd prefer to do so as we learn about them, instead of opportunistically, for now.

Makes sense!

2. Ah, yea, the response body. We'd need to add some sort of classify_async_fn (naming hard).

Ah, yes, this then likely will need to be an async method.

The harder part though, is that if you stream/consume the response body, what happens to the exposed body on Response after the retry says it's all good? Is it gone? Would we need some sort of replayable body, or a way for you to put it back?

Indeed, optimally for our use case we'd want to retrieve the (final) error payload once the retries are exhausted, as we have to bubble up the embedded application layer error code/message.

But, it seems for now we could work around it by (also) utilizing the returned HTTP status codes.