fetching pull requests failed in infinite loop when proxy is unavailable
jsoref opened this issue · comments
Type: Bug
- Open a terminal
- Run
export http_proxy=http://localhost:3128;export https_proxy=http://localhost:3128
- Do not have anything listening on that port.
- Have a clone of https://github.com/fireship-io/fireship.io
- Have 3 remotes in it:
fireship.io % git remote -v
check-spelling https://github.com/check-spelling-sandbox/fireship.io.git (fetch)
check-spelling https://github.com/check-spelling-sandbox/fireship.io.git (push)
jsoref https://github.com/jsoref/fireship.io.git (fetch)
jsoref https://github.com/jsoref/fireship.io.git (push)
origin git@github.com:fireship-io/fireship.io.git (fetch)
origin git@github.com:fireship-io/fireship.io.git (push)
- Use
code .
to open the repository in vscode (inheriting the proxy) - Open the Pull Requests sidebar
- Expand Pull Requests
- Click
Created By Me
to expand - See infinite loop of things
vscode.github.pull.requests.errors.mov
Expected results:
- Do not have an infinite loop
- Error messages should be visible long enough for a user to do something to them
- Whatever the underlying error is also shouldn't happen, but I'm more concerned by the first two points.
Extension version: 0.90.0
VS Code version: Code 1.90.2 (Universal) (5437499feb04f7a586f677b155b039bc2b3669eb, 2024-06-18T22:37:41.291Z)
OS version: Darwin arm64 23.5.0
Modes:
System Info
Item | Value |
---|---|
CPUs | Apple M1 Max (10 x 2400) |
GPU Status | 2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled webgpu: enabled |
Load (avg) | 5, 5, 5 |
Memory (System) | 64.00GB (0.70GB free) |
Process Argv | --crash-reporter-id 1fc67ee2-0174-4598-9f98-4537df0dd32c |
Screen Reader | no |
VM | 0% |
A/B Experiments
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492:30256859
vscoreces:30445986
vscod805cf:30301675
binariesv615:30325510
vsaa593:30376534
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
vscrp:30673768
962ge761:30959799
pythongtdpath:30769146
welcomedialogc:30910334
pythonnoceb:30805159
asynctok:30898717
pythonregdiag2:30936856
pythonmypyd1:30879173
h48ei257:31000450
pythontbext0:30879054
accentitlementst:30995554
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
jchc7451:31067544
chatpanelc:31048052
dsvsc021:30996838
945dj816:31013170
pythoncenvpt:31062603
a69g1124:31058053
dvdeprecation:31068756
dwnewjupytercf:31046870
newcmakeconfigv2:31071590
impr_priority:31082723
The underlying error is:
Fetching pull requests failed: request to https://api.github.com/repos/fireship-io/fireship.io/pulls?per_page=20&page=1 failed, reason: Failed to establish a socket connection to proxies: ["PROXY localhost:3128"]
![image](https://private-user-images.githubusercontent.com/2119212/342968322-4cc9700b-c3fa-4d58-a45d-523812d4281e.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTk3MzA2NTcsIm5iZiI6MTcxOTczMDM1NywicGF0aCI6Ii8yMTE5MjEyLzM0Mjk2ODMyMi00Y2M5NzAwYi1jM2ZhLTRkNTgtYTQ1ZC01MjM4MTJkNDI4MWUucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDYzMCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA2MzBUMDY1MjM3WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9OWY0Yjg3ZTAxNTMzNGMyNjE4Yzk3ZGQ3MzRjNGQwZTY3OWY4Njg5ZjExNjE1ZjM3OTgzN2JjZjVmMDQwYWRhOSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.xdmxkqcPuAWNxfrgeWrbEiZKXt2CYx5lhestRSGxs5g)
... This is similar to #5814, but I'm on macOS, not in China, and there is no proxy, ...
so testing, fixing, and validating should be easy to do, and I should be responsive for at least the next month...