You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Failed request when opening a file accompanied by an analysis_options.yaml #3929
Opening a file in VSCode using File:open and selecting the file works fine if there is no analysis_options.yaml present.
If I create a dart file in a directory, with an analysis_options.yaml file next to it (contents don't seem to matter), and then use File:open to open that file from VSCode (without there already being a folder open) then I get the following error:
[Error - 4:27:32 PM] Request textDocument/documentSymbol failed.
Message: File is not being analyzed
Code: -32007
/Users/leafp/tmp/example.dart
[Error - 4:27:32 PM] Request textDocument/colorPresentation failed.
Message: File is not being analyzed
Code: -32007
/Users/leafp/tmp/example.dart
Expected behavior
Either no error (ideally) or an error message that tells me how to resolve the issue.
Screenshots
Upon request.
Please complete the following information: Please complete the following information:
Operating System and version: Darwin leafp-macbookpro2.roam.internal 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:46:32 PDT 2022; root:xnu-8020.101.4~15/RELEASE_ARM64_T6000 arm64
VS Code version:
Version: 1.66.2 (Universal)
Commit: dfd34e8260c270da74b5c2d86d61aee4b6d56977
Date: 2022-04-11T07:49:20.994Z (4 days ago)
Electron: 17.2.0
Chromium: 98.0.4758.109
Node.js: 16.13.0
V8: 9.8.177.11-electron.0
OS: Darwin arm64 21.4.0
I can repro this. I think it's a race condition (perhaps that came in when setting analysis roots became async). VS Code tells the server the file was opened, and then sends requests for a few things, including document symbols. I think that request is being processed before the roots have been set (which is now an async operation that waits for some watchers ready events, so could easily allow other requests to be processed before it's complete):
1650128847288:Req:{"jsonrpc"::"2.0","id"::11,"method"::"textDocument/documentSymbol","params"::{"textDocument"::{"uri"::"file::///private/tmp/darttest/foo.dart"}}}
1650128847289:Res:{"id"::11,"jsonrpc"::"2.0","error"::{"code"::-32007,"message"::"File is not being analyzed","data"::"/private/tmp/darttest/foo.dart"}}
... if you modify the file so the request is sent again (without changing anything else), it succeeds:
if a request triggers this condition and analysis roots are in the process of being rebuilt/discovered, wait for that to complete, then check again if the file is being analyzed
while analysis roots are being rebuilt, lock the request queue so no other requests begin processing until complete (this could be done using the mechanism recently added to do something similar for completions)
I think the second would probably be best (it would make the behaviour when changing roots more like it was when it was synchronous), but I'll do some testing.
The only advantage I can think of for the first is that we might be able to respond more quickly in some situations, but I think those situations are going to be uncommon enough that either is a reasonable solution.
The first turns out to be a little easier to implement too. The second requires taking the lock before any async boundaries, but for this case (no explicit roots, implied roots from open files) the are quite a few places the code goes before the rebuild starts and I'd rather not have to rely on (or ensure) none of those ever get any async code.
Activity
DanTup commentedon Apr 16, 2022
I can repro this. I think it's a race condition (perhaps that came in when setting analysis roots became async). VS Code tells the server the file was opened, and then sends requests for a few things, including document symbols. I think that request is being processed before the roots have been set (which is now an async operation that waits for some watchers
readyevents, so could easily allow other requests to be processed before it's complete):... if you modify the file so the request is sent again (without changing anything else), it succeeds:
Some possible fixes could be:
I think the second would probably be best (it would make the behaviour when changing roots more like it was when it was synchronous), but I'll do some testing.
bwilkerson commentedon Apr 16, 2022
The only advantage I can think of for the first is that we might be able to respond more quickly in some situations, but I think those situations are going to be uncommon enough that either is a reasonable solution.
@scheglov For visibility.
DanTup commentedon Apr 19, 2022
The first turns out to be a little easier to implement too. The second requires taking the lock before any async boundaries, but for this case (no explicit roots, implied roots from open files) the are quite a few places the code goes before the rebuild starts and I'd rather not have to rely on (or ensure) none of those ever get any async code.
[analysis_server] Wait for analysis context rebuilds when obtaining p…
DanTup commentedon Apr 19, 2022
Fix landed in dart-lang/sdk@422c23a. Let me know if you still see this (or anything like it) when you're on an SDK that includes that change. Thanks!
[analysis_server] Fix handling of semantic tokens when roots are bein…