unwrap() panic on long execution times

[jhheider]

ref: https://github.com/pkgxdev/pantry/actions/runs/20583075159/job/59114465481

drill --benchmark /tmp/tmp.FDBHjkdNjX.yml --stats
Concurrency 4
Iterations 5
Rampup 2
Base URL http://pkgx.sh/

Fetch root                http://pkgx.sh/ 200 OK 692ms
Fetch root                http://pkgx.sh/ 200 OK 693ms
Fetch root                http://pkgx.sh/ 200 OK 694ms
Fetch root                http://pkgx.sh/ 200 OK 142ms
Fetch root                http://pkgx.sh/ 200 OK 5332ms

thread 'main' (6090) panicked at /home/builder/actions-runner/_work/pantry/pantry/homes/crates.io__drill-0.9.0/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/hdrhistogram-7.5.4/src/lib.rs:1864:28:
called `Result::unwrap()` on an `Err` value: ValueOutOfRangeResizeDisabled
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: <hdrhistogram::Histogram<T> as core::ops::arith::AddAssign<u64>>::add_assign
   4: drill::compute_stats
   5: drill::show_stats
   6: drill::main

Notable is the fifth fetch runs 5 seconds, which is going to exceed the histogram configuration:

  let mut hist = Histogram::<u64>::new_with_bounds(1, 60 * 60 * 1000, 2).unwrap();

So, the likely fixes are likely one of:

• trap long runs as a handled error case
• adapt the histogram bounds to exceed the longest fetch time
• discard, with warning, "excessively-long" fetches.

The second probably makes the most sense, grabbing a quick iteration over the reports, and clamping to some histogram upper bound.

Notably, if I start mucking with line 119,

  for r in sub_reports.iter() {
    // hist += (r.duration * 1_000.0) as u64;
    hist += (4100.0 * 1_000.0) as u64;
  }

works fine, and

  for r in sub_reports.iter() {
    // hist += (r.duration * 1_000.0) as u64;
    hist += (4200.0 * 1_000.0) as u64;
  }

fails. Reading hdrhistogram suggests that they can take an auto_resize flag as well, which might be the simplest solution.

[jhheider]

Notably, --timeout 4 completely "fixes" (masks) this issue. I wonder if timeout should be in milliseconds, rather than seconds for usability.

[jhheider]

I'll let this be in a moment, but this seems like (potentially) one complete fix:

-  let mut hist = Histogram::<u64>::new_with_bounds(1, 60 * 60 * 1000, 2).unwrap();
+  let mut hist = Histogram::<u64>::new(2).unwrap();

adding a 42s (42,000ms) duration works perfectly fine with auto_resize.