Tobias Bieniek

just brainstorming here: would it make sense to extract a `IntoResponseResult` (or `IntoFallibleResponse` or ...) trait, where anything that implements `IntoResponse` automatically implements `IntoResponseResult`? then we could keep combining responses...

yep, I'll give it a try.

 unfortunately still failing 😢

> Can I have a look at the code and the test? [the code yes](https://github.com/rust-lang/crates.io/blob/873bc1f5f87fc49ba74e5f962c2b48eba0d0e6d8/src/worker/jobs/downloads/process_log.rs#L157-L161), the test no. unfortunately we don't have a test that reproduces it. I can only...

the panic appears to be gone, but we're now seeing an "interval out of range" error result without a stacktrace. I will have to improve our logging a bit to...

> we're now seeing an "interval out of range" error it turns out that this was a bug on our side, related to how we calculate exponential backoff for failed...

thanks again for the investigation, fix and release! I just merged the latest update into crates.io :)

Since we can't `impl IntoResponse for !` due to https://github.com/rust-lang/rust/issues/35121, I don't think there is much we can do about this 🤔

out of curiosity, what is the use case for supporting unconditional `panic!()` in the first place? it seems to me that for prototyping code `todo!()` might be a better fit,...

are you sure about that? my understating is that that todo macro uses a generic return type and behaves differently from panic in that regard. I agree that writing the...