-
Notifications
You must be signed in to change notification settings - Fork 27.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code actions can be requested on document that is not yet opened #83338
Comments
I've starting debugged this and it looks like Starting with a file
@alexandrudima or @bpasero: Do you know why this may be happenig? Is it expected? |
@bpasero I can confirm this does not happen for plain text files. Can you test using a TS file containing a quick fix. I just tested this using the oss build (no extensions) in an empty workspace and can still repo this in a TS file using my original repo steps: |
How? |
@bpasero I think the workbench is acting a bit funny around renaming, but I am not sure if it is necessarily a bug... On the second rename the workbench no longer disposes the old model, but it decides to keep it around, even if the file is deleted on disk... which is a bit bizarre. I have disabled git to reduce noise with text models. Here is how things look like for an extension:@mjbvz Here is how it looks from an extension point of view I have done the following diff to TS in Rename
Rename
Rename
Here is how things look like in our
|
I am not convinced. This must be something else. We have a very simple ref-counting model of text editor models. The editor will try to dispose the model when it gets closed, but if someone else managed to get hold of the model (via This smells like the extension host asking for a reference to the model (for the quick fix?) and then holding onto the model for a while (@jrieken might know) and only then dispose it. I think the issue here is that the extension host is not disposing the reference at the time it is not needed anymore, but only after a delay. |
PS: the reason why I think another party is involved is that I still cannot reproduce this when simply having an empty file
|
👍 Yeah, I'm pretty sure the fact that we see code actions (which must be disposed!!) has something to do with it... So the ball moves to @jrieken to investigate who is doing model references which prevent the model from getting disposed. |
The extension host is only doing that when an extension calls @mjbvz where is that assertion you see failing? It is not this, right? Is this inside tsserver and how is that being updated? |
So, looks like TS itself is calling Tho, I don't know where tsserver is missing the document. The extension host has it, otherwise the call to the code action provider wouldn't event happen (see my previous comment). |
Perhaps tsserver is listening to file change events from the disk and on the disk the file is deleted ? |
Thank you for looking into this. I now have a better understanding of what is going on. I think the root cause is that the lifetime of a Here is the sequence of events:
I'm going to look into who is holding on to these text documents that prevents the |
Issue Type: Bug
Repo
a.ts
with the contentconst i = error
b.ts
a.ts
b.ts
Bug
See
unexpected resource
printed in the dev tools consoleThe root cause seems to be that we end up requesting code actions for
b.ts
before it that file is properly reopened. I added logs inonDidAddTextDocument
andprovideCodeActions
. Here's what they show:Noticed how in the last few frames actions are requested for
b.ts
before theopen
forb.ts
is firedVS Code version: Code - OSS Dev 1.40.0 (Commit unknown, Date unknown)
OS version: Darwin x64 18.7.0
System Info
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
protected_video_decode: unavailable_off
rasterization: enabled
skia_renderer: disabled_off
surface_control: disabled_off
surface_synchronization: enabled_on
video_decode: enabled
viz_display_compositor: enabled_on
viz_hit_test_surface_layer: disabled_off
webgl: enabled
webgl2: enabled
The text was updated successfully, but these errors were encountered: