stuck on generating

[Tom89757]

Type: Bug

Inline suggestion is available. When chatting with it, it stuck on Generating....

Extension version: 0.20.0 VS Code version: Code 1.93.0 (4849ca9bdf9666755eb463db297b69e5385090e3, 2024-09-04T13:02:38.431Z) OS version: Windows_NT x64 10.0.19045 Modes:

System Info

|Item|Value| |---|---| |CPUs|11th Gen Intel(R) Core(TM) i5-11400 @ 2.60GHz (12 x 2592)| |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
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: enabled
webnn: disabled_off| |Load (avg)|undefined| |Memory (System)|15.81GB (5.61GB free)| |Process Argv|D:\\Desktop\\RefRepos\\RK3588-55inch-rotate\\SkgFileManager --crash-reporter-id 1ef9292a-b7b1-45fb-887a-ac3236260cff| |Screen Reader|no| |VM|29%|

A/B Experiments

``` vsliv368:30146709 vspor879:30202332 vspor708:30202333 vspor363:30204092 vscod805cf:30301675 binariesv615:30325510 vsaa593cf:30376535 py29gd2263:31024239 c4g48928:30535728 azure-dev_surveyone:30548225 a9j8j154:30646983 962ge761:30959799 pythongtdpath:30769146 welcomedialog:30910333 pythonnoceb:30805159 asynctok:30898717 pythonmypyd1:30879173 h48ei257:31000450 pythontbext0:30879054 accentitlementsc:30995553 dsvsc016:30899300 dsvsc017:30899301 dsvsc018:30899302 cppperfnew:31000557 dsvsc020:30976470 pythonait:31006305 dsvsc021:30996838 bdiig495:31013172 a69g1124:31058053 dvdeprecation:31068756 dwnewjupyter:31046869 impr_priority:31102340 refactort:31108082 pythonrstrctxt:31112756 wkspc-onlycs-t:31132770 wkspc-ranged-c:31125598 ei213698:31121563 ```

[Tom89757]

just like this.

[Tom89757]

Copilot encountered the same issue on both local VSCode on two computers, but it works fine when connected to the remote server.

[lramos15]

Can you include your logs via CMD / CTRL + SHIFT +U -> Github Copilot Chat

[Tom89757]

Can you include your logs via CMD / CTRL + SHIFT +U -> Github Copilot Chat

It outputs nothing. The same issue is now occurring when connecting to remote servers.

[Tom89757]

Can you include your logs via CMD / CTRL + SHIFT +U -> Github Copilot Chat

It outputs nothing. The same issue is now occurring when connecting to remote servers.

Now it works fine on the server, but it takes a long time to respond on the local computer and still gets stuck at 'generating'

[lramos15]

And I assume locally you're using 0.20.0 just like you are on the server?

Do you have any interesting network or proxy configuration? Can you try F1 -> Chat Diagnostics as well

[Tom89757]

And I assume locally you're using 0.20.0 just like you are on the server?

Do you have any interesting network or proxy configuration? Can you try F1 -> Chat Diagnostics as well

On one of my local computers, no proxy is configured, and it shows as follows:

On the server, no proxy is configured either, and it shows as follows:

On my other local computer, I usually use a proxy. I will post the results as soon as possible.

[Tom89757]

On a computer where I use a proxy(I have Clash for Windows enabled, but I haven't configured http_proxy in VSCode.), it displays as follows:

[lramos15]

F1 -> Set Log Level -> Trace then repro the issue. It will give you more information to better understand where we're getting stuck

[Tom89757]

F1 -> Set Log Level -> Trace then repro the issue. It will give you more information to better understand where we're getting stuck

On the local computer where no proxy is configured:

On the server:

[Tom89757]

On the local computer using a proxy:

[chrmarti]

@Tom89757 Could you start VS Code with --log-net-log=netlog.json, retry asking Copilot (locally) and then share the created netlog.json here?

[Tom89757]

The output from the local computer using a proxy is as follows: netlog.json

[chrmarti]

It picks up the proxy configuration from the OS. Could you also append a netlog from the machine showing the problem without proxy, so we are sure it is not the proxy causing any issues?

[Tom89757]

It picks up the proxy configuration from the OS. Could you also append a netlog from the machine showing the problem without proxy, so we are sure it is not the proxy causing any issues?

The output without the proxy is as follows: netlog.json

[chrmarti]

Not sure what might be the issue here. The first SSL_CONNECT_JOB to api.githubcopilot.com fails, but the second one succeeds. Maybe that is an indication for an underlying problem.

On the machine without proxy, could you try adding the following to your user settings (F1 > Preferences: Open User Settings (JSON):

  "github.copilot.advanced": {
    "debug.useElectronFetcher": false,
    "debug.useNodeFetcher": true
  }

Then reload the window to make the updated settings apply and the retry the Chat.

[Tom89757]

Not sure what might be the issue here. The first SSL_CONNECT_JOB to api.githubcopilot.com fails, but the second one succeeds. Maybe that is an indication for an underlying problem.

On the machine without proxy, could you try adding the following to your user settings (F1 > Preferences: Open User Settings (JSON):

  "github.copilot.advanced": {
    "debug.useElectronFetcher": false,
    "debug.useNodeFetcher": true
  }

Then reload the window to make the updated settings apply and the retry the Chat.

Thanks for your reply. It works!!!

[Tom89757]

Not sure what might be the issue here. The first SSL_CONNECT_JOB to api.githubcopilot.com fails, but the second one succeeds. Maybe that is an indication for an underlying problem. On the machine without proxy, could you try adding the following to your user settings (F1 > Preferences: Open User Settings (JSON):

  "github.copilot.advanced": {
    "debug.useElectronFetcher": false,
    "debug.useNodeFetcher": true
  }

Then reload the window to make the updated settings apply and the retry the Chat.

Thanks for your reply. It works!!!

Regardless of whether a proxy is used

[chrmarti]

Could you check if the following variation also works:

  "github.copilot.advanced": {
    "debug.useElectronFetcher": false,
    "debug.useNodeFetcher": false
  }

[deepak1556]

Just looked into the logs, couple of data points extracted from them.

In the proxy server case:

All HTTP2 sessions irrespective of the remote host end up getting closed from the proxy server 127.0.0.1:7890 after 60s of starting the session. I wonder if the proxy has some timeout configuration or it cannot handle h2 sessions well.

In the direct connection case:

SSL_CONNECT_JOB failure was due to SSL handshake failure (event entry 264) on the first request to https://api.githubcopilot.com/agents, I wonder if it has to do with the TCP port used for connection 58021.

@Tom89757 couple of followups, with the following settings

"github.copilot.advanced": {
    "debug.useElectronFetcher": true,
    "debug.useNodeFetcher": false
  }

1) On the machine with proxy server, can you restart the application with --disable-http2 and see if connection works. If it fails please provide the netlog for this case. 2) On the machine without proxy server, can you capture another fresh netlog with the issue reproing.

[Tom89757]

Could you check if the following variation also works:

  "github.copilot.advanced": {
    "debug.useElectronFetcher": false,
    "debug.useNodeFetcher": false
  }

It also works.

[Tom89757]

Just looked into the logs, couple of data points extracted from them.

In the proxy server case:

All HTTP2 sessions irrespective of the remote host end up getting closed from the proxy server 127.0.0.1:7890 after 60s of starting the session. I wonder if the proxy has some timeout configuration or it cannot handle h2 sessions well.

In the direct connection case:

SSL_CONNECT_JOB failure was due to SSL handshake failure (event entry 264) on the first request to https://api.githubcopilot.com/agents, I wonder if it has to do with the TCP port used for connection 58021.

@Tom89757 couple of followups, with the following settings

"github.copilot.advanced": {
    "debug.useElectronFetcher": true,
    "debug.useNodeFetcher": false
  }

1. On the machine with proxy server, can you restart the application with --disable-http2 and see if connection works. If it fails please provide the netlog for this case.
2. On the machine without proxy server, can you capture another fresh netlog with the issue reproing.

On the machine without proxy server, the problem has occurred again. I will try it on another computer as soon as possible and provide feedback

[Tom89757]

Just looked into the logs, couple of data points extracted from them.

In the proxy server case:

All HTTP2 sessions irrespective of the remote host end up getting closed from the proxy server 127.0.0.1:7890 after 60s of starting the session. I wonder if the proxy has some timeout configuration or it cannot handle h2 sessions well.

In the direct connection case:

SSL_CONNECT_JOB failure was due to SSL handshake failure (event entry 264) on the first request to https://api.githubcopilot.com/agents, I wonder if it has to do with the TCP port used for connection 58021.

@Tom89757 couple of followups, with the following settings

"github.copilot.advanced": {
    "debug.useElectronFetcher": true,
    "debug.useNodeFetcher": false
  }

1. On the machine with proxy server, can you restart the application with --disable-http2 and see if connection works. If it fails please provide the netlog for this case.
2. On the machine without proxy server, can you capture another fresh netlog with the issue reproing.

On the machine with proxy server, it fails.

[Tom89757]

Just looked into the logs, couple of data points extracted from them. In the proxy server case: All HTTP2 sessions irrespective of the remote host end up getting closed from the proxy server 127.0.0.1:7890 after 60s of starting the session. I wonder if the proxy has some timeout configuration or it cannot handle h2 sessions well.

In the direct connection case: SSL_CONNECT_JOB failure was due to SSL handshake failure (event entry 264) on the first request to https://api.githubcopilot.com/agents, I wonder if it has to do with the TCP port used for connection 58021. @Tom89757 couple of followups, with the following settings

"github.copilot.advanced": {
    "debug.useElectronFetcher": true,
    "debug.useNodeFetcher": false
  }

1. On the machine with proxy server, can you restart the application with --disable-http2 and see if connection works. If it fails please provide the netlog for this case.
2. On the machine without proxy server, can you capture another fresh netlog with the issue reproing.

The Screenshot may be helpful:

[deepak1556]

In both the new logs, 101 (ERR_CONNECTION_RESET) is only seen for telemetry related requests. All requests from copilot seem to complete fine.

@Tom89757 can you attach the trace log from copilot chat extension when running with --disable-http2. Also I will delete your last two logs since requests succeeded and the headers contain github tokens.

[chrmarti]

Could you check if the following variation also works: "github.copilot.advanced": { "debug.useElectronFetcher": false, "debug.useNodeFetcher": false }

It also works.

@Tom89757 Just to make sure the setting was properly applied: Did you reload the VS Code window after changing the setting before you checked if it works? (Reloading the window is required to make the settings change effective.)

[Tom89757]

In both the new logs, 101 (ERR_CONNECTION_RESET) is only seen for telemetry related requests. All requests from copilot seem to complete fine. 重试    错误原因

@Tom89757 can you attach the trace log from copilot chat extension when running with --disable-http2. Also I will delete your last two logs since requests succeeded and the headers contain github tokens.

Do you mean with previous settings you give? Here is the log:

[Tom89757]

Could you check if the following variation also works: "github.copilot.advanced": { "debug.useElectronFetcher": false, "debug.useNodeFetcher": false }

It also works.

@Tom89757 Just to make sure the setting was properly applied: Did you reload the VS Code window after changing the setting before you checked if it works? (Reloading the window is required to make the settings change effective.)

I reload the window and it also works.