uv pip install produces spurious panics #17898
Description
Summary
Hello. We're seeing spurious errors every few times we run on macOS when using uv pip install. We are behind a PyPI mirror on Sonatype Nexus, so trying to work out if this crash is related to what is being served by Nexus or whether it is a bug in UV itself. Unfortunately, the existing UV logging around this is making working this out quite difficult.
Locally, we see the following output:
$ uv pip install --exact --link-mode=copy --no-cache --no-compile-bytecode --python-platform=x86_64-manylinux_2_28 --python-version=3.13 --reinstall --requirements=/path/to/requirements.txt --target=/path/to/data
Using CPython 3.14.2 interpreter at: .venv/bin/python3
⠦
thread 'main2' (516424) panicked at /Users/runner/work/uv/uv/crates/uv-metadata/src/lib.rs:253:53:
called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: reqwest::Error { kind: Decode, source: reqwest::Error { kind: Body, source: hyper::Error(Body, Error { kind: Reset(StreamId(211), PROTOCOL_ERROR, Remote) }) } } }
stack backtrace:
0: 0x104bafff0 - __mh_execute_header
1: 0x1047ac5e0 - __mh_execute_header
2: 0x104baf7f8 - __mh_execute_header
3: 0x104bafe90 - __mh_execute_header
4: 0x104baf494 - __mh_execute_header
5: 0x104bcee64 - __mh_execute_header
6: 0x104bcedd4 - __mh_execute_header
7: 0x104bcedc8 - __mh_execute_header
8: 0x106416cf4 - __mh_execute_header
9: 0x106417378 - __mh_execute_header
10: 0x104f97c6c - __mh_execute_header
11: 0x1055581f8 - __mh_execute_header
12: 0x105766bb0 - __mh_execute_header
13: 0x1057635d8 - __mh_execute_header
14: 0x10575b58c - __mh_execute_header
15: 0x1057565f0 - __mh_execute_header
16: 0x10574c27c - __mh_execute_header
17: 0x1057a47b0 - __mh_execute_header
18: 0x10514a19c - __mh_execute_header
19: 0x105308ac4 - __mh_execute_header
20: 0x1045616f0 - __mh_execute_header
21: 0x104578b04 - __mh_execute_header
22: 0x104535148 - __mh_execute_header
23: 0x1046b3360 - __mh_execute_header
24: 0x105581a94 - __mh_execute_header
25: 0x104ff2430 - __mh_execute_header
26: 0x104bda160 - __mh_execute_header
27: 0x19133bbc8 - __pthread_cond_wait
thread 'main' (516422) panicked at /Users/runner/work/uv/uv/crates/uv/src/lib.rs:2648:10:
Tokio executor failed, was there a panic?: Any { .. }
stack backtrace:
0: 0x104bafff0 - __mh_execute_header
1: 0x1047ac5e0 - __mh_execute_header
2: 0x104baf7f8 - __mh_execute_header
3: 0x104bafe90 - __mh_execute_header
4: 0x104baf494 - __mh_execute_header
5: 0x104bcee64 - __mh_execute_header
6: 0x104bcedd4 - __mh_execute_header
7: 0x104bcedc8 - __mh_execute_header
8: 0x106416cf4 - __mh_execute_header
9: 0x106417378 - __mh_execute_header
10: 0x10557b080 - __mh_execute_header
11: 0x105580e68 - __mh_execute_header
12: 0x1055dfbac - __mh_execute_header
$ echo $?
101
I've managed to trace the issue through to what I believe is caused by a Result<(), X> being forcefully unwrap()ped without handling it if an error occurs.
uv/crates/uv-metadata/src/lib.rs
Line 253 in 0ba4324
It would be very useful to us if this could output the exact error in a human readable format, along with details of what the actual operation being performed was (i.e. what kind of resource this is failing on handling) so that, if needed, we can raise a meaningful bug report with yourselves to look into the root issue.
Unfortunately, I won't be able to build this locally to try and debug it.
Many thanks.
Platform
macOS 24.6.0 Darwin Kernel Version 24.6.0 arm64
Version
0.9.26
Python version
3.14.2