Editor appears to be hanging loading file after re-registering FileSystemProvider

[IlyaBiryukov]

Issue Type: Bug

VS Code version: Code 1.28.1 (3368db6, 2018-10-11T18:13:53.910Z)
OS version: Windows_NT x64 10.0.17763

When VSCode opens a document with custom scheme, if at this point the file system provider registered for this scheme is disposed, VSCode editor just keeps loading the document forever, even if a new file system provider is registered for the same scheme.

We have to dispose of the file system provider and register a new one because we want to change read-only status of the provider. The only way to do that is to do dispose-re-register for the same scheme.

Ideally, if VSCode allowed to change read-only status of the provider on the fly, without the need for disposing-re-registering, this should help us avoid the issue.

Or, alternatively, If VSCode cannot load the document because the file system provider got disposed in the middle of reading, VSCode should not try to load the document anymore and should close its editor window.

When this issue happens I see a TypeError exception is thrown:

TypeError: Cannot read property 'readFile' of undefined
    at e.$readFile (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:492:286)
    at t._doInvokeHandler (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:640:888)
    at t._invokeHandler (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:640:554)
    at t._receiveRequest (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:639:126)
    at t._receiveOneMessage (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:638:59)
    at c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:635:926
    at c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:98:138
    at e.fire (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:99:496)
    at a (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:154:213)
    at Socket.n._socketDataListener (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:154:432)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at addChunk (_stream_readable.js:263:12)
    at readableAddChunk (_stream_readable.js:250:11)
    at Socket.Readable.push (_stream_readable.js:208:10)
    at Pipe.onread (net.js:594:20)

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Extension crashed while doing code completion (#60442)
• ERR Cancelled Request 1646: Error: Cancelled Request 1646 (#58781)
• Debugging my extension: Cannot find modul '...\out\extension' (#57668)
• Node debugger starting failed. (#60227)
• removeFromRecentlyOpened Command Broken (#58131)

[IlyaBiryukov]

It seems this issue happens when in src\vs\workbench\services\files\electron-browser\remoteFileService.ts in _readFile() the file system provider is disposed after stat() succeeds and before read() commences. In this case the errors emitted from Readable created by createReadableOfProvider are not properly handled by the downstream code.

[isidorn]

@IlyaBiryukov thanks for nice investigation.
Assigning to @jrieken since it seems to me that the readFile should fail more gracefully
Feel free to bounce back to me..

[jrieken]

@isidorn I have pushed a change that makes sure the error doesn't get stuck in streams and that the error is somewhat more meaningful. However, for the full deal story we should cancel file loads when its provider is gone and/or close editors that don't have a provider anymore

[vscodebot]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodebot]

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding

[vscodebot]

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!