Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

`python.analysis` setting changes (e.g. `completeFunctionParens`) are not picked up until reload

Closed Beginner friendly
  • Is something wrong?
#5,084 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
86/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust, typescript, vscode
Domain
developer-experience, tooling

Research direction

Start in lsp/src/extension.ts around the configuration-change handler at lines 383-389, then read pyrefly/lib/lsp/non_wasm/server.rs around did_change_configuration. Verify how python.analysis changes are detected and ensure the next completion request uses the updated setting without a reload; confirm both enabling and disabling completeFunctionParens behave as expected.

Written by the indexing model from the issue text.

Description

language-server
Describe the Bug

When a user changes a python.analysis.* setting such as python.analysis.completeFunctionParens, Pyrefly keeps using the value it read at startup. The new value only takes effect after a window reload or server restart.

Reproduction

  1. Set "python.analysis.completeFunctionParens": true and reload so Pyrefly picks it up.
  2. In a Python file, trigger completion on a function name. The item inserts name($0) as expected.
  3. Change the setting to false without reloading.
  4. Trigger completion again. The item still inserts name($0).
  5. Reload the window, or change any python.pyrefly.* setting. Completions now insert name with no parentheses.

The same happens in the other direction (enabling the setting), and step 5 shows the server picks up the new value as soon as it re-reads its settings for any reason.

Expected behavior

Pyrefly applies the new value on the next completion request, without a reload.

Root cause

The server side is ready for this. did_change_configuration (pyrefly/lib/lsp/non_wasm/server.rs, around line 4738) re-pulls settings for all workspaces when the client supports workspace/configuration, and otherwise applies the pushed python settings.

The notification just never arrives for python.analysis changes:

  • The VS Code extension only sends workspace/didChangeConfiguration when python.pyrefly changes or when the active interpreter changes (lsp/src/extension.ts, lines 383-389 on main, commit ef6de648b).
  • The language client has no synchronize configuration section, and the server does not dynamically register for workspace/didChangeConfiguration either.

Possible fixes:

  • In lsp/src/extension.ts, also send the notification when event.affectsConfiguration('python.analysis'), or 'python' more broadly. This is a one-line change.
  • Alternatively, have the server dynamically register for workspace/didChangeConfiguration on the python section when the client advertises dynamicRegistration support. This would also fix other LSP clients that do not push configuration changes.

Would you all be up for me contributing a PR implementing the first one-line option?

Sandbox Link

No response

(Only applicable for extension issues) IDE Information

No response

Dominant language
Rust
Stars
7.1k
Forks
564
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from facebook/pyrefly

All issues in facebook/pyrefly

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.