lsp_shutdown iterates over _request_futures while it may be mutated concurrently

[meymchen]

Component

pygls/protocol/language_server.py

Summary

lsp_shutdown loops over self._request_futures.items() and calls future.cancel() on each. If a future completes in another thread and its done-callback pops it from _request_futures during this iteration, Python raises RuntimeError: dictionary changed size during iteration, crashing the server.

Steps to Reproduce

1. Have multiple in-flight requests running in the thread pool.
2. Trigger shutdown while some of those requests finish concurrently.
3. Server crashes with RuntimeError.

Expected Behavior

Shutdown should gracefully cancel pending requests without crashing.

Actual Behavior

Dictionary mutation during iteration causes a fatal RuntimeError.

Affected Code (pygls/protocol/language_server.py, ~L209-211)

for msg_id, future in self._request_futures.items():
    if msg_id != current_id and not future.done():
        future.cancel()

Proposed Fix

Iterate over a snapshot:

for msg_id, future in list(self._request_futures.items()):
    if msg_id != current_id and not future.done():
        future.cancel()

[tombh]

May I ask if you are human or bot? Can you explain how you identified all these issues today? How did you submit them, manually or with an agent? Why do you prefer to submit these as issues rather than PRs?

[meymchen]

May I ask if you are human or bot? Can you explain how you identified all these issues today? How did you submit them, manually or with an agent? Why do you prefer to submit these as issues rather than PRs?

Sorry, I'm still human—just with AI assisting me through the submission process. My private project made over thirty modifications to pygls to accommodate tree-sitter and AI systems. These issues were generated by Claude based on the code changes and my comments. I've submitted them as issues rather than PRs because I'm unsure whether these changes align with your design philosophy or if they rely on workarounds/hacks that might not be desirable. I felt it was better to discuss and confirm first. If you approve of these changes, I'd be happy to submit PRs to address them.

[tombh]

I am not against receiving LLM-assisted contributions in principle. But I will need some convincing that these issues are worthwhile. Submitting 10 templated issues as you have done appears spam-like, which is not a good way to introduce yourself to an open source project. As I hope you are well aware LLMs are known to hallucinate. So I would like some indication that you are genuinely and sincerely involved in each of the changes.

I think a good way to start would be to submit just a single issue, preferably written by yourself, that explains your situation. You could also submit a small PR alongside that demonstrating the kind of change you would like to contribute. We can go through the process of reviewing and merging that. If that goes well, then we can look at merging more.

[meymchen]

Thank you for the honest feedback — I completely understand your concern, and I apologize for the poor first impression.

To clarify a few things:

These issues were not hallucinated or discovered by an LLM. I'm an algorithm engineer working on AI coding tools at a game company, and my team built an internal project on top of pygls with over thirty modifications to support tree-sitter integration and AI-assisted workflows. Every one of these issues came from real problems I hit during that work — they are reproducible and grounded in actual code changes I've already made and tested internally.

The LLM's role was limited to formatting and submitting the issues based on my code diffs and notes. I used it the same way someone might use a template or a script — to save time on write-up, not to generate findings.

As for why I submitted them as separate issues rather than a single PR: I'm also building an Agent Harness — a framework for evaluating AI coding assistants against real tasks. Decomposing changes into small, well-scoped issues is part of that methodology, designed to make each problem easier to discuss, review, and collaborate on (whether with humans or AI). It was not intended as spam, and I see now how it came across that way without context. That's on me.

I'm happy to follow your suggested approach: I'll consolidate my situation into a single issue written entirely by myself, and attach a small PR for one concrete fix (such as this one) so you can evaluate the quality and intent directly. If that goes well, we can proceed incrementally from there.

Thank you for keeping the door open. I respect how you maintain this project and I'd like to contribute properly.