Repository navigation
[Bug][0.21] Models load requires 10+ minutes, Chat does not work till then #408
Description
Environment
- OS: RHEL 9.6
- Eclipse Version: 4.38 & latest 4.41nightly
- Plugin Version: 0.21.0
Describe the bug
Follow up on initially reported freeze, which I can't reproduce anymore.
But beside the freeze there seem to be a model loading issue which breaks Chat conversation.
Tried same question on same file today, it worked once after IDE was running for few ours. To double check, restarted IDE, asked exact same question again, and got no response at all, cancellation seem not freeze at this time.
The bug seems to be that something with model loading prevents agents (in ask mode) to respond. I've tried to switch model, restart Chat view, ask to /simplify code - no ways, there are no errors, but nothing happens, Chat remains empty, cancellation works and not freezes.
Common in all cases: if it works, I see "models" loaded in preference page. If it doesn't, models page is showing "loading..." text. As soon as the preference page starts to show models, Chat view starts to receive input from LS.
Here are models I can see:
It seems that model loading is the problem and it seems that it hangs now for multiple minutes.
Here is what I see in the log file, the big delay between 11:26 and 11:38 is when the models are NOT shown and Chat does not work:
!ENTRY org.eclipse.lsp4e 1 0 2026-08-10 11:26:28.882
!MESSAGE [LS:GitHub Copilot Language Server][Info] [AuthManager] resolveSession: persisted store resolved a session
!ENTRY org.eclipse.lsp4e 1 0 2026-08-10 11:38:54.829
!MESSAGE [LS:GitHub Copilot Language Server][Info] [AuthManager] resolveSession: persisted store resolved a session
!ENTRY org.eclipse.lsp4e 1 0 2026-08-10 11:38:54.882
!MESSAGE [LS:GitHub Copilot Language Server][Info] [AuthManager] resolveSession: persisted store resolved a session
!ENTRY org.eclipse.lsp4e 1 0 2026-08-10 11:38:56.315
!MESSAGE [LS:GitHub Copilot Language Server][Info] [agentPrompt] Rendering fresh global context for conversation/turn 6a3e3fb1-9edd-4196-9895-05a8c26287d6/41ccf120-86f5-4052-a697-ffb57e91bbfe
!ENTRY org.eclipse.lsp4e 1 0 2026-08-10 11:38:57.350
!MESSAGE [LS:GitHub Copilot Language Server][Info] [fetchChat] Request 43c34464-0502-4c16-b763-8ca25b326aa9 at <https://api.enterprise.githubcopilot.com/v1/messages> finished with 200 status after 1003.0455470000161ms
!ENTRY org.eclipse.lsp4e 1 0 2026-08-10 11:39:25.225
!MESSAGE [LS:GitHub Copilot Language Server][Info] [roundMetricsTracker] Turn token usage: 16738 prompt, 2442 completion, 3325 cached (cache rate: 19.9%)
!ENTRY org.eclipse.lsp4e 1 0 2026-08-10 11:39:25.237
!MESSAGE [LS:GitHub Copilot Language Server][Info] [AuthManager] resolveSession: persisted store resolved a session
!ENTRY org.eclipse.lsp4e 1 0 2026-08-10 11:39:25.876
!MESSAGE [LS:GitHub Copilot Language Server][Info] [fetchChat] Request 341cc5d5-bd73-437f-8794-b289be2d0e1f at <https://api.enterprise.githubcopilot.com/chat/completions> finished with 200 status after 638.2802089999896ms
!ENTRY org.eclipse.lsp4e 1 0 2026-08-10 11:39:26.167
!MESSAGE [LS:GitHub Copilot Language Server][Info] [streamMessages] message 0 returned. finish reason: [stop]
Video shows a faster load which "only" took ~3 minutes:
smt8_2026-08-10_12-50-04.mp4
Not sure what changed in Internet or whether it depends on the Moon position.
Below linked is the full log file. This time I see more interesting entries:
!ENTRY org.eclipse.lsp4e 1 0 2026-08-10 12:48:52.710
!MESSAGE [LS:GitHub Copilot Language Server][Info] [AuthManager] resolveSession: persisted store resolved a session
!ENTRY org.eclipse.lsp4e 1 0 2026-08-10 12:51:34.413
!MESSAGE [LS:GitHub Copilot Language Server][Info] [fetcher] Request to <https://telemetry.enterprise.githubcopilot.com/telemetry> failed, attempting fallback. Error [TypeError]: fetch failed
at Object.processResponse (/snapshot/copilot-language-server-internal/dist/main.js:302:32970)
at /snapshot/copilot-language-server-internal/dist/main.js:302:39314
at node:internal/process/task_queues:149:7
at AsyncResource.runInAsyncScope (node:async_hooks:214:14)
at AsyncResource.runMicrotask (node:internal/process/task_queues:146:8)
at process.processTicksAndRejections (node:internal/process/task_queues:103:5) {
code: 'UND_ERR_SOCKET',
syscall: undefined,
errno: undefined,
[cause]: SocketError: HTTP/2: "GOAWAY" frame received with code 0
at ClientHttp2Session.onHttp2SessionGoAway (/snapshot/copilot-language-server-internal/dist/main.js:213:4264)
at ClientHttp2Session.emit (node:events:519:28)
at Http2Session.onGoawayData (node:internal/http2/core:748:11) {
code: 'UND_ERR_SOCKET',
socket: {
localAddress: '10.206.48.60',
localPort: 56286,
remoteAddress: '140.82.112.21',
remotePort: 443,
remoteFamily: 'IPv4',
timeout: undefined,
bytesWritten: 522,
bytesRead: 3407
}
}
}
!ENTRY org.eclipse.lsp4e 1 0 2026-08-10 12:51:34.413
!MESSAGE [LS:GitHub Copilot Language Server][Info] [fetcher] Request to <https://dc.services.visualstudio.com/v2/track> failed, attempting fallback. Error [TypeError]: fetch failed
at Object.processResponse (/snapshot/copilot-language-server-internal/dist/main.js:302:32970)
at /snapshot/copilot-language-server-internal/dist/main.js:302:39314
at node:internal/process/task_queues:149:7
at AsyncResource.runInAsyncScope (node:async_hooks:214:14)
at AsyncResource.runMicrotask (node:internal/process/task_queues:146:8)
at process.processTicksAndRejections (node:internal/process/task_queues:103:5) {
code: 'ECONNRESET',
syscall: 'read',
errno: -104,
[cause]: Error: read ECONNRESET
at TLSWrap.onStreamRead (node:internal/stream_base_commons:216:20) {
errno: -104,
code: 'ECONNRESET',
syscall: 'read'
}
}
!ENTRY org.eclipse.lsp4e 1 0 2026-08-10 12:51:34.479
!MESSAGE [LS:GitHub Copilot Language Server][Info] [AuthManager] resolveSession: persisted store resolved a session
Activity
jdneo commentedon Aug 11, 2026
You mean this is stable reproducible?
iloveeclipse commentedon Aug 11, 2026
On my site, yes, at least two days before. I will try again today. Basically the effect is, that I have to wait some minutes after IDE start to use Chat. Didn't happened with 0.20.
iloveeclipse commentedon Aug 11, 2026
Just tried few times. Today tried with Claude Sonnet 4.6 instead of Claude Opus 4.8, doesn't make a difference. Already started Eclipse, running since yesterday: Chat answers immediately. Eclipse started fresh: first attempt to "/explain" small 100 lines shell file: ~1 minute. Started again, asked about other, a bit bigger Java file (300 lines): hangs for over 12 minutes. Again, if it hangs, "models" on the preference page don't show up.
Yet again different log entries (I've given up after 10 minutes and tried to cancel). Note that the stack trace indicates that the preference page tried to update itself after it was closed (I've opened and closed that to validate whether the models were loaded or not).
iloveeclipse commentedon Aug 11, 2026
Tried once again, same file, same model, same question (but I didn't cancelled) - 12 minutes wait time and no error messages, just nothing for 12 minutes.
jdneo commentedon Aug 11, 2026
How is your proxy setting in eclipse?
iloveeclipse commentedon Aug 11, 2026
Never set any:
iloveeclipse commentedon Aug 11, 2026
Not sure if a specific server query for obtaining model information is now added to latest CLS shipped with 0.21 plugin, which somehow runs into initialization timeout and prevents agents to work? Any specific log / trace I can enable to see what's going on in CLS while Eclipse is waiting?
jdneo commentedon Aug 12, 2026
Ethan Hou (@ethanyhou) Could you please check this issue, pay attention to:
iloveeclipse commentedon Aug 12, 2026
Another bad side effect of this issue is that Eclipse shutdown is blocked as long as the models info is not fetched yet, via this code:
iloveeclipse commentedon Aug 12, 2026
I'm not sure if there could be any problems with the related code or data or Copilot user sessions / authentication if one runs multiple IDE's at same time (each one starts its own native CLS process as I see it in the process list). I typically have multiple IDE's opened for different projects I'm working on in parallel.
jdneo commentedon Aug 13, 2026
Andrey Loskutov (@iloveeclipse) That's a point that I haven't thought.
What will happen if you work on single eclipse instance?
iloveeclipse commentedon Aug 13, 2026
Just tried this, checked before that no copilot LS server instances running (just in case) - no success.
Here are some log entries which might be related?
Between these two messages below Copilot Chat was not reacting on the prompt and was waiting for 13 minutes:
jdneo commentedon Aug 14, 2026
What if set a system level env variable GH_COPILOT_USE_HELIX_FETCHER=true?
iloveeclipse commentedon Aug 28, 2026
The "models" preference page seem to load fast, but I've got UI freeze while switching from "agent" to "ask" mode in the Chat view even before being able to ask something :-(
I also noticed there is this process using 100% CPU
This is the process started by Eclipse:
iloveeclipse commentedon Aug 28, 2026
Note: the CPU load by
copilot-language-serverprocess is not related to theGH_COPILOT_USE_HELIX_FETCHERvariable, I've simply not noticed before that, but I see that correlates with the current problem of Chat "hanging".Pstack shows this:
iloveeclipse commentedon Aug 28, 2026
I've asked second Copilot instance to check the stack & current Copilot process running and it seems that CPU load is caused by the very big git repo we have (cwd of the language server has 55 GB, 82 566 directories):
Were there any changes related to the how the workspace watches are managed by Copilot?
iloveeclipse commentedon Aug 28, 2026
Looks like this was this one: #373
travkin79 commentedon Oct 22, 2026
After talking to Andrey Loskutov (@iloveeclipse),
I could reproduce the issue on my RHEL workstation. After doing some experiments, here are some preliminary analysis results. I think, we have multiple issues here.
Environment:
RHEL 9, Eclipse 4.38 (build 4.38.8.v20260910-1358), Java 25 (Adoptium),
Copilot for Eclipse 0.21.0.202610121610 (nightly), Copilot Language Server (CLS) 1.541.0.
Workspace with 411 open projects.
1. NPE when sending a chat message right after startup → chat view stays unresponsive
Reproduced twice (17:20:55 and 17:31:29, each ~20 s after Eclipse started the CLS):
Timeline from the LSP4E trace (session started 17:31):
copilot/modelssent → answered 17:31:25.636copilot/byok/listModelssent (twice) → answered 17:31:30.724 ({"models":[]})No
conversation/createorconversation/turnrequest was ever sent to the CLS. The chat viewgave no answer, even after the CLS was idle again (~13 min later). All other requests from the
plugin were answered by the CLS.
2. CLS process at ~100 % CPU for minutes after startup
copilot-language-serveruses ~100 % of one core (RES ~1 GB) for ~13 minutes after start, thendrops below 1 %. This happens even when no chat request is sent.
(customization lists, BYOK model list).
copilot/modelswas answered within ~2 s. After CLS finished its busy work,shutdownwasanswered in 24 ms.
3. All 411 projects are sent to the CLS as workspace folders, probably handled twice
initializecontains 411workspaceFolders(73 KB request), andworkspace/didChangeWorkspaceFolderssends the same 411 folders again as
addeddirectly afterinitialized.conversation/templates,conversation/modes,copilot/customAgent/list,copilot/customSkill/list,copilot/customPrompt/list,copilot/customInstruction/listeach carry the full list (~70 KB per request).file:///…/Project/(ininitialize,conversation/templates) andfile:/…/Project(in the other requests).copilot/customInstruction/listreturned 52 project-level.github/copilot-instructions.mdfiles.4. CLS processes outliving Eclipse / extra CLS started during shutdown
copilot-language-serverprocesses were running atthe same time, both at ~100 % CPU. The one from the closed Eclipse instance ended later.
ExecutionException occurred during shutdown of EndpointProxy … java.io.IOException: Stream closed,and in the same millisecond range the plugin logged
Starting language server with binary lsp agent./Binary agent started successfully.,i.e. a new CLS was started while Eclipse was shutting down.
iloveeclipse commentedon Oct 23, 2026
Note: I do not observe same 10+ minutes blocking in a different workspace, which contains ~350 projects with much more files (100.000 vs 150.000), there is almost no blocking.
The main difference between good and bad workspace is, that in the "bad" workspace (10+ minutes blocking) all 400+ projects are in a single but very big git repository which also has lot of symbolic links (e.g. for bazel output).
Without links:
find . -type f | wc -l: 458.872With links:
find -L . -type f | wc -l: 5.881.095The "good" workspace has ~10 different git repos with 357.763 files overall (no symbolic links).
travkin79 commentedon Oct 23, 2026
Even in the "bad" workspace, I do not always observe the 10+ minutes blocking. If I send a copilot request quickly, it seems to work, but the CLS process becomes busy for 10+ minutes anyway, the process seems to begin its work just a little later and that work happens even without me sending any copilot request.
travkin79 commentedon Oct 23, 2026
I reproduced this on RHEL 9 with a workspace of ~400 Eclipse projects from one large Git repository
(plugin 0.21.0, CLS 1.527.0). I've created some PRs that make the situation better, but it seems, the bug fix needs to be implemented on CLS side.
Observations
initialize(~400 workspace folders) and the followingworkspace/didChangeWorkspaceFolders, theCLS answers the model and
customInstruction/listrequests, then produces no output for ~8 minutes. Aconversation/createandbyok/listApiKeyssent meanwhile are only answered after that.strace -f -cshows no file system crawling (nogetdents64,openat,inotify_add_watchduring the busy phase), onlyfutex/mmap/munmap/madviseand almost noepoll_pwait:synchronous JavaScript blocking the Node event loop, with GC churn.
~7× fewer projects -> ~70× less time, i.e. super-linear in the number of workspace folders.
UserPreferenceService.dispose()onconversation/persistence(answered after 11 min 41 s);
shutdown/exitare sent only afterwards. A busy CLS does not react to themanyway, so it can outlive Eclipse and keep the CPU busy.
workspaceFolders()override, so LSP4E now announces everyproject instead of only the workspace root.
CLS side (from the minified
dist/main.jsof@github/copilot-language-server1.527.0 and 1.541.0)Class names are preserved in the bundle. The likely hot path:
WorkspaceLifecycleManager.onWorkspacesAddedcallsawait listener.didAddWorkspace(folder)for everylistener and every added folder.
PromptServiceignores the folder and callsrewatchAll().rewatchAll()callsrewatch(type)for each of 5 customization file types(
agent,skill,prompt,instructions,hook).rewatch()callscurrentWorkspacePaths(),resolvePatterns(...)andwatcher.watch(...).currentWorkspacePaths()sorts all folders and checks each one against all others for nesting: O(N²).For N folders that is about N × 5 × O(N²) work, all synchronous (
awaiton non-I/O work only yieldsmicrotasks), so the event loop is blocked and no other request is processed.
Suggestions for the CLS:
didAddWorkspacecall per folder.PromptService, debounce/coalescerewatchAll()or only add watches for the new folder.currentWorkspacePaths()/ resolved patterns between calls.This code path is unchanged in CLS 1.541.0 (used on
main).PRs
available.
while shutting down.
phase; might be rejected in favour of a CLS fix.
These complement #452 – #455 (no UI freezes / shutdown hangs while the CLS is busy), which do not address the busy
CLS itself.
FYI Andrey Loskutov (@iloveeclipse), #504 solves the 10+ minutes hang for us, but might require some more tests.
fix: announce only workspace root to CLS