[ty] Configure check mode for all projects by BurntSushi · Pull Request #23121 · astral-sh/ruff

BurntSushi · 2026-02-06T13:26:45Z

Previously, we were only setting the check mode on a project if the
diagnostic mode was workspace. While the diagnostic mode defaults to
OpenFilesOnly, the check mode on a ty project defaults to AllFiles
(i.e., workspace).

The result is that projects were always configured in AllFiles check
mode, making it impossible to set the check mode to OpenFilesOnly.
Confusingly, this is distinct from the global settings diagnostic
mode, which could actually be different thant he check mode on the
individual projects!

This did cause one test failure: an end-to-end test checking that
changing the language of a file resulted in the LSP picking up that
change. e.g., Going from Python to non-Python should result in no
diagnostics. This was added in #21867, but I believe the change was
incomplete: when a didOpen notification is received, we were
unconditionally adding the file to the project state without checking
its extension. The test still "worked" precisely because of the
AllFiles vs OpenFilesOnly confusion. That is, the server defaulted
to OpenFilesOnly, but the project defaulted to AllFiles. This in
turn made it so the file was an "open file" and not actually picked up
from a directory scan. That in turn led to should_check_file returning
false, since the AllFiles mode explicitly ignores "open files."

Ref astral-sh/ty#2616

BurntSushi · 2026-02-06T14:05:05Z

The test failure is real here I think. It was previously not setting the diagnostic mode, which in turn defaulted to Workspace. Now it defaults to OpenFilesOnly and this causes diagnostics to be reported for a file whose type got changed. That's problem number 1. Problem number 2 is that if I set its diagnostic mode explicitly to Workspace, then the test fails, but because it never gets a publishDiagnostic response. So there is actually something different between explicitly setting the diagnostic mode to Workspace and letting it use defaults. That's what I'm investigating now.

Previously, we were only setting the check mode on a project if the diagnostic mode was `workspace`. While the diagnostic mode defaults to `OpenFilesOnly`, the _check mode_ on a ty project defaults to `AllFiles` (i.e., workspace). The result is that projects were always configured in `AllFiles` check mode, making it impossible to set the check mode to `OpenFilesOnly`. Confusingly, this is _distinct_ from the global settings diagnostic mode, which could actually be different thant he check mode on the individual projects! This did cause one test failure: an end-to-end test checking that changing the language of a file resulted in the LSP picking up that change. e.g., Going from Python to non-Python should result in no diagnostics. This was added in #21867, but I believe the change was incomplete: when a `didOpen` notification is received, we were unconditionally adding the file to the project state without checking its extension. The test still "worked" precisely because of the `AllFiles` vs `OpenFilesOnly` confusion. That is, the server defaulted to `OpenFilesOnly`, but the project defaulted to `AllFiles`. This in turn made it so the file was an "open file" and not actually picked up from a directory scan. That in turn led to `should_check_file` returning false, since the `AllFiles` mode explicitly ignores "open files." Ref astral-sh/ty#2616

BurntSushi · 2026-02-06T17:47:33Z

crates/ty_server/tests/e2e/publish_diagnostics.rs

    };
    server.send_notification::<DidOpenTextDocument>(params);
-    let _close_diagnostics = server.await_notification::<PublishDiagnostics>();
-


I'm not sure if it was intentional to have the diagnostics send back twice, but this is no longer the case. It was happening previously because:

Closing the document (above) would result in clearing diagnostics only when DocumentHandle::close returns true. And that would return true because session.global_settings().diagnostic_mode().is_open_files_only() returned true. Because the session global settings used OpenFilesOnly by default.

Re-opening the document (with the language ID changed) caused publish_diagnostics_if_needed inside of the DidOpenTextDocumentHandler handler to run. This would eventually do Project::check_file and that would call should_check_file. And that would return false because the projects have been defaulting to AllFiles as a check mode by default, and the file in question is only in the "open file" set. (Which is perhaps a bug on its own, but I digress.)

The end result is that the test got no diagnostics which was what was expected, but it got for a reason other than respecting the change in language ID. Once I fixed the AllFiles/OpenFilesOnly problem, this test started failing because we would still send back diagnostics for the plain text file.

I ended up fixing this by checking the language ID of the file in the DidOpenTextDocumentHandler handler. If it's Other, then we ignore it, hopefully mirroring what we do in ty_project/src/walk.rs.

dhruvmanila

Uff, this seemed like very confusing to debug, thanks for tracking this down!

dhruvmanila · 2026-02-09T05:24:38Z

crates/ty_server/src/server/api/notifications/did_open.rs

-        let document = session.open_text_document(
-            TextDocument::new(uri, text, version).with_language_id(&language_id),
-        );
+        let text_doc = TextDocument::new(uri, text, version).with_language_id(&language_id);
+        if matches!(text_doc.language_id(), Some(LanguageId::Other)) {
+            return Ok(());
+        }

+        let document = session.open_text_document(text_doc);


I think this sounds correct but it would be useful to have a E2E test case for this scenario if it doesn't already exists. What do you think?

I think this is what the changing_language_of_file_without_extension test covers. That the test was previously passing was a mirage. :-) Once I untangled the AllFiles/OpenFilesOnly stuff, it started failing. Adding this was required to make it pass because otherwise we treat the open file as Python code.

dhruvmanila · 2026-03-03T10:09:58Z

crates/ty_server/src/server/api/notifications/did_open.rs

+        if matches!(text_doc.language_id(), Some(LanguageId::Other)) {
+            return Ok(());
+        }


This check does seem to be causing some confusion because if this is true then the document won't be opened and the following notifications for this document would result in "Document ... is not open in the session" logs (astral-sh/ty#2824 (comment), astral-sh/ty#2937).

Yeah, we should probably move it below line 39 (I'm also not entirely sure why it's needed)

I think the idea was to mirror what we do in ty_project/src/walk.rs: #23121 (comment)

I think I was thinking about this in particular: https://github.com/astral-sh/ruff/blob/f8d1d29ec7f1ff0da7e0272c8388036f35e815b7/crates/ty_project/src/walk.rs#L240-L228

But it's possible I misinterpreted what that code is doing. @MichaReiser Can you say why this should be moved? Or would it make sense to emit a log or something in this case?

Specifically, this was my attempt at fixing the changing_language_of_file_without_extension test, which started failing after I unwound the check mode configuration stuff.

The issue with not opening the document in the session is that any LSP action on any document with LanguageId::Other will fail to look up the document (e.g., didChange, didClose, etc.), and they'll log a warning on every request.

That's why I think that we always need to add the document to Index (let handle = self.index_mut().open_text_document(document);), but we may want to skip calling project.open_file(db, file); if the document is a non Python file in open_document_in_db.

OK, I put up a PR for that change here: #23704

In #22449, I added a check to our "did open" handler to effectively ignore notifications for text documents that we were sure weren't Python. This was meant to fix a case where we could return diagnostics for non-Python files, which was undesirable. However, it seems like that might have been too big of a hammer. It seems like we might still want to track non-Python text files in our index but not our project. Otherwise subsequent requests regarding that non-Python file result in log messages saying that ty doesn't know about the file. i.e., a state synchronization issue. Addresses #23121 (comment)

BurntSushi requested review from Gankra, MichaReiser, carljm, dcreager and sharkdp as code owners February 6, 2026 13:26

BurntSushi requested review from dhruvmanila and removed request for Gankra, MichaReiser, carljm, dcreager and sharkdp February 6, 2026 13:26

ntBre added the ty Multi-file analysis & type inference label Feb 6, 2026

BurntSushi added the server Related to the LSP server label Feb 6, 2026

BurntSushi force-pushed the ag/fix-check-mode branch from 6c25981 to 07f565f Compare February 6, 2026 17:40

BurntSushi commented Feb 6, 2026

View reviewed changes

dhruvmanila approved these changes Feb 9, 2026

View reviewed changes

BurntSushi merged commit 49a25f2 into main Feb 9, 2026
46 checks passed

BurntSushi deleted the ag/fix-check-mode branch February 9, 2026 14:49

dhruvmanila reviewed Mar 3, 2026

View reviewed changes

dhruvmanila mentioned this pull request Mar 3, 2026

No diagnostics for LSP client that uses different language identifier astral-sh/ty#2937

Open

BurntSushi mentioned this pull request Mar 4, 2026

[ty] Fix handling of non-Python text documents #23704

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[ty] Configure check mode for all projects#23121

[ty] Configure check mode for all projects#23121
BurntSushi merged 1 commit intomainfrom
ag/fix-check-mode

BurntSushi commented Feb 6, 2026 •

edited

Loading

Uh oh!

BurntSushi commented Feb 6, 2026

Uh oh!

BurntSushi Feb 6, 2026

Uh oh!

dhruvmanila left a comment

Uh oh!

dhruvmanila Feb 9, 2026

Uh oh!

BurntSushi Feb 9, 2026 •

edited

Loading

Uh oh!

Uh oh!

dhruvmanila Mar 3, 2026

Uh oh!

MichaReiser Mar 3, 2026

Uh oh!

BurntSushi Mar 3, 2026

Uh oh!

MichaReiser Mar 4, 2026

Uh oh!

BurntSushi Mar 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

BurntSushi commented Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BurntSushi commented Feb 6, 2026

Uh oh!

BurntSushi Feb 6, 2026

Choose a reason for hiding this comment

Uh oh!

dhruvmanila left a comment

Choose a reason for hiding this comment

Uh oh!

dhruvmanila Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

BurntSushi Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

dhruvmanila Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

MichaReiser Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

BurntSushi Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

MichaReiser Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

BurntSushi Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

BurntSushi commented Feb 6, 2026 •

edited

Loading

BurntSushi Feb 9, 2026 •

edited

Loading