Fix hanging `MessagesPoll.Poll` #4325

Felixoid · 2026-01-01T21:25:12Z

PR Prelude

Thank you for working on YCM! :)

Please complete these steps and check these boxes (by putting an x inside
the brackets) before filing your PR:

I have read and understood YCM's CONTRIBUTING document.
I have read and understood YCM's CODE_OF_CONDUCT document.
I have included tests for the changes in my PR. If not, I have included a
rationale for why I haven't.
I understand my PR may be closed if it becomes obvious I didn't
actually perform all of these steps.

Why this change is necessary and useful

Vim hangs when editing Rust files with YCM + rust-analyzer. The PR fixes #4272.

MessagesPoll.Poll uses blocking HandleFuture, that's why it happens. This causes the main vim process to hang for a few seconds. HandleFuture() performs heavy synchronous operations:

User interaction dialogs - UnknownExtraConf prompts that block waiting for user input.
Vim UI updates - DisplayServerException() status line updates.
Complex exception handling - multiple try/except layers with logging.
Python evaluation overhead - the parf+flamegraph showed 649k+ CPU cycles in 5 seconds while debugging.

All of this runs synchronously in vim's main thread during timer callbacks, freezing the UI.

The fix still calls response.read(), which is technically blocking I/O. However, this is acceptable because:

Future is already done() - we only call read() after done() returns True, meaning the HTTP response is complete
Localhost communication - ycmd server runs on localhost, so network latency is negligible
Data already received - read() just copies from the response buffer to memory, no actual network wait
Minimal processing - just JSON parsing, no user interaction or complex exception handling

This change is

puremourning · 2026-01-01T22:55:40Z

python/ycm/client/messages_request.py

-    response = self.HandleFuture( self._response_future,
-                                  display_message = False )
+    # Non-blocking extraction since done() is True. We avoid HandleFuture()
+    # because it calls response.read() which blocks on large responses.


this code also calls response.read() so please can you explain in the comment and in detail in the PR description why this fixes the issue?

puremourning · 2026-01-01T22:58:46Z

Thanks for the PR!

I'm still a bit confused why this change actually fixes it though. I get that if there's a huge message we have to block to read it, but this code still has to read it and it's still going to run in the vim main thread.

codecov · 2026-01-01T23:01:03Z

Codecov Report

❌ Patch coverage is 90.90909% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 75.38%. Comparing base (d11e24d) to head (8043981).
⚠️ Report is 12 commits behind head on master.

❌ Your changes status has failed because you have indirect coverage changes. Learn more about Unexpected Coverage Changes and reasons for indirect coverage changes.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4325      +/-   ##
==========================================
+ Coverage   75.29%   75.38%   +0.09%     
==========================================
  Files          30       30              
  Lines        2898     2913      +15     
==========================================
+ Hits         2182     2196      +14     
- Misses        716      717       +1

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Felixoid · 2026-01-01T23:08:01Z

Sure, added it to the PR description and extended the code comment.

puremourning · 2026-01-01T23:18:16Z

python/ycm/client/messages_request.py

-                                  display_message = False )
+    # Avoid HandleFuture() to prevent blocking in timer callbacks.
+    # HandleFuture() does:
+    #   1. Complex exception handling (UnknownExtraConf, DisplayServerException)


so? why is this a problem in this case? do we have a trivial/minimal repro case?

puremourning · 2026-01-01T23:18:33Z

python/ycm/client/messages_request.py

+    # Avoid HandleFuture() to prevent blocking in timer callbacks.
+    # HandleFuture() does:
+    #   1. Complex exception handling (UnknownExtraConf, DisplayServerException)
+    #   2. User dialogs that can block waiting for input


No it doesn't, at least, not in any relevant codepath.

puremourning · 2026-01-01T23:19:22Z

python/ycm/client/messages_request.py

+    # HandleFuture() does:
+    #   1. Complex exception handling (UnknownExtraConf, DisplayServerException)
+    #   2. User dialogs that can block waiting for input
+    #   3. Vim UI updates during callback execution


So does this code. I mean, that's its literal job : HandlePollResponse will do UI updates, that's what it's for.

puremourning · 2026-01-01T23:22:22Z

python/ycm/client/messages_request.py

+    #   2. User dialogs that can block waiting for input
+    #   3. Vim UI updates during callback execution
+    # By extracting the response directly with minimal error handling, we avoid
+    # blocking vim's main thread. Note that response.read() is still technically


citation needed?

If response.done() is True then HandleFuture (which just calls JsonFromFuture) will just do the exact thing this code does, except this code skips HMAC validation, which is absolute Nope. Skipping HMAC validation is a security issue and we can't accept it.

I'm honestly not convinced by this change, and the explanation seems ... synthetic to me.

I'm willing to believe there is indeed an issue when there are very big notification messages (such as huge diagnostics) but I'd like to have a more convincing explanation and maybe the flame graph, profile, or whatever was mentioned in the description.

Thank you for the detailed review. I'm sorry you're upset with a generated answer.

I didn't test the fix well enough. Most likely, I concluded it was fixed before the entire dataset was indexed by rust-analyzer, and it still freezes, but I didn't reproduce it before submitting the PR.

flamegraph-1.tar.gz

Here's the original flamegraph + perf.script data I used for it.

flamegraph-2.tar.gz

The second flamegraph looks similar, since I waited until the data was loaded. For the one that showed an improvement, I only have a flamegraph; the perf data has been overwritten.

flamegraph-3.tar.gz

I'll dig a bit deeper into it, but it looks like there's no easy solution.

Thank you for your time, and happy New Year 2026!

Felixoid · 2026-01-02T11:54:53Z

Sorry for submitting trash. There's no easy fix for this particular issue.

puremourning · 2026-01-02T16:05:49Z

Hey, no worries! Thanks for the contribution!

Actually, you've provided some good data here.

I have experienced something similar myself and I actually just remembered that I made a hack in my fork to work around it. The hack was to restrict the length of any given diagnostic range. IIRC the problem was adding text properties that spanned entire functions led to really really bad results client side.

If I get some time I might try to reproduce and fix it.

Felixoid · 2026-01-02T21:41:53Z

The repro is relatively trivial.

Install YCM as Plug 'ycm-core/YouCompleteMe', { 'do': 'git submodule update --init --recursive && ./install.py --rust-completer' }
clone https://github.com/mozilla/sccache/
open any file in the repo, for example, src/util.rs
After the data is loaded and indexed (around 10-40 seconds), editing the file becomes challenging
Adding an empty line with a comment // or removing it causes freezes for a second or more

Felixoid added 2 commits January 1, 2026 21:55

Unblock hanging main process

243f533

Add tests for non-blocking MessagesPoll

9697813

Felixoid mentioned this pull request Jan 1, 2026

Vim hangs when YouCompleteMe handles many syntax errors over many lines #4272

Open

12 tasks

Fix tests

ceb61d4

puremourning reviewed Jan 1, 2026

View reviewed changes

Add comment, why plain response.read is used in MessagesPoll.Poll

c09e0f3

Fix flake8

8043981

puremourning reviewed Jan 1, 2026

View reviewed changes

Felixoid closed this Jan 2, 2026

Fix hanging MessagesPoll.Poll #4325

Fix hanging MessagesPoll.Poll #4325

Uh oh!

Conversation

Felixoid commented Jan 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Prelude

Why this change is necessary and useful

Uh oh!

puremourning Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

puremourning commented Jan 1, 2026

Uh oh!

codecov bot commented Jan 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Felixoid commented Jan 1, 2026

Uh oh!

puremourning Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

puremourning Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

puremourning Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

puremourning Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

Felixoid Jan 2, 2026

Choose a reason for hiding this comment

Uh oh!

Felixoid commented Jan 2, 2026

Uh oh!

puremourning commented Jan 2, 2026

Uh oh!

Felixoid commented Jan 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Fix hanging `MessagesPoll.Poll` #4325

Fix hanging `MessagesPoll.Poll` #4325

Felixoid commented Jan 1, 2026 •

edited

Loading

codecov bot commented Jan 1, 2026 •

edited

Loading