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
Support refreshing single files in diagnostic pull #1669
This makes Pylance continuously do analysis. At least for items that don't seem to save the fact that there are no errors. (Previous result ids don't exist for files that aren't open, but workspace mode asks for all files).
I'm not sure if the polling is as design (might be) but missing the previous result id seems like a bug?
Our result contains all files though. The next poll request only has a previous result id for the file that's open. If all previous results were passed, we would mark the next request as unchanged, but we can't because of the missing result ids for the unopened files.
Rich Chiodo (@rchiodo) the idea of workspace pull is that you as long as possible keep the request open (don't return a response and stream results on file changes into the request). Are you closing the request after every pull?
The refresh request indicates to the client that a new pull is required? I guess we could just use the spots where we ask for a refresh to instead send more progress, but for workspace diagnostics, we'll essentially have the same logic we have for push mode.
I've reimplemented our workspace diagnostics to use the partial results model and it seems better. We don't reanalyze everything on the refresh. Instead, we just send changes as they happen.
So, I'm not sure how it could be better. Maybe if there was a way to say 'refresh this file'? We know which ones need to have analysis redone, but maybe that's not the same for all language servers.
This makes Pylance continuously do analysis. At least for items that don't seem to save the fact that there are no errors. (Previous result ids don't exist for files that aren't open, but workspace mode asks for all files).
I'm not sure if the polling is as design (might be) but missing the previous result id seems like a bug?
Our result contains all files though. The next poll request only has a previous result id for the file that's open. If all previous results were passed, we would mark the next request as unchanged, but we can't because of the missing result ids for the unopened files.
Activity
dbaeumer commentedon Aug 19, 2025
Rich Chiodo (@rchiodo) the idea of workspace pull is that you as long as possible keep the request open (don't return a response and stream results on file changes into the request). Are you closing the request after every pull?
rchiodo commentedon Aug 19, 2025
Oh, we just return as soon as we have all of the results. So, we should be using partial results?
That seems like push mode instead of pull.
dbaeumer commentedon Aug 22, 2025
It is a long running pull. There is no indication on the client side to when trigger a new pull. That is why it is implemented that way.
rchiodo commentedon Aug 22, 2025
The refresh request indicates to the client that a new pull is required? I guess we could just use the spots where we ask for a refresh to instead send more progress, but for workspace diagnostics, we'll essentially have the same logic we have for push mode.
dbaeumer commentedon Aug 28, 2025
The difference to the old model is that the file and workspace pull are coordinated.
I am open for a feature that only pulls once and then waits for a refresh.
rchiodo commentedon Aug 28, 2025
I've reimplemented our workspace diagnostics to use the partial results model and it seems better. We don't reanalyze everything on the refresh. Instead, we just send changes as they happen.
So, I'm not sure how it could be better. Maybe if there was a way to say 'refresh this file'? We know which ones need to have analysis redone, but maybe that's not the same for all language servers.
parsa2000200 commentedon Sep 2, 2025
[-]Workspace diagnostics continually poll[/-][+]Support refreshing single files in diagnostic pull[/+]