VS Code 1.62 breaks the extension. Downgrade to 1.61

[kpowick]

It seems that a recent update of VS Code has broken the extension. I updated VS Code on my Mac and, other than syntax highlighting, the extension stopped working. However, it did work on my Linux VM, until I updated VS Code there as well. ☹️

Can anyone confirm this issue with their own VS Code?

VS Code info
Version: 1.62.3
Commit: ccbaa2d27e38e5afa3e5c21c1c7bef4657064247
Date: 2021-11-17T07:59:13.865Z
Electron: 13.5.2
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin x64 21.1.0

[itsxallwater]

Pete mentioned he'd heard similar. Will try and take a look next week.

[mail2lawi]

Interestingly I was just here to report the same issue.
1.62 broke the extension on Ubuntu as well. Downgrading back to 1.61 restored the functionality

[kpowick]

Thanks for the confirmation.

I have also downgraded VS Code back to 1.61.2 and the extension is working again.

Downloads for VS Code 1.61.2 can be found at the following link.

https://code.visualstudio.com/updates/v1_61

[kpowick]

Now that we know what's happened, and the temporary solution, I'm pinning this issue and changing the title so it's prominent.

[dthiot]

You probably want to disable automatic updates too as that is the default in settings. Change it to manual.

[itsxallwater]

Fingers crossed I'll have a window to dig into this a little more this week but here's a snippet from the Log (Extension Host) output on my machine. My guess/hope here is that we just need a few package updates.

[2021-12-06 10:03:38.041] [exthost] [error] Activating extension mvextensions.mvbasic failed due to an error:
[2021-12-06 10:03:38.041] [exthost] [error] Error: find port exited with code 1
    at findPort (c:\Users\mikew\.vscode\extensions\mvextensions.mvbasic-2.1.2\client\node_modules\sync-rpc\lib\index.js:63:11)
    at start (c:\Users\mikew\.vscode\extensions\mvextensions.mvbasic-2.1.2\client\node_modules\sync-rpc\lib\index.js:32:16)
    at sendMessage (c:\Users\mikew\.vscode\extensions\mvextensions.mvbasic-2.1.2\client\node_modules\sync-rpc\lib\index.js:133:17)
    at createClient (c:\Users\mikew\.vscode\extensions\mvextensions.mvbasic-2.1.2\client\node_modules\sync-rpc\lib\index.js:173:27)
    at Object.<anonymous> (c:\Users\mikew\.vscode\extensions\mvextensions.mvbasic-2.1.2\client\node_modules\sync-request\lib\index.js:16:14)
    at Module.u._compile (c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\loader.js:4:1316)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1155:10)
    at Module.load (internal/modules/cjs/loader.js:982:32)
    at Module._load (internal/modules/cjs/loader.js:823:14)
    at Function.f._load (electron/js2c/asar_bundle.js:5:12913)
    at Function.n._load (c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:113:28606)
    at Function.b._load (c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:113:25193)
    at Function.h._load (c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:103:60406)
    at Module.require (internal/modules/cjs/loader.js:1006:19)
    at h (c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\loader.js:4:699)
    at Object.5670 (c:\Users\mikew\.vscode\extensions\mvextensions.mvbasic-2.1.2\client\out\extension.js:1:290169)
    at i (c:\Users\mikew\.vscode\extensions\mvextensions.mvbasic-2.1.2\client\out\extension.js:1:290378)
    at Object.3260 (c:\Users\mikew\.vscode\extensions\mvextensions.mvbasic-2.1.2\client\out\extension.js:1:258922)
    at i (c:\Users\mikew\.vscode\extensions\mvextensions.mvbasic-2.1.2\client\out\extension.js:1:290378)
    at Object.8311 (c:\Users\mikew\.vscode\extensions\mvextensions.mvbasic-2.1.2\client\out\extension.js:1:281973)
    at i (c:\Users\mikew\.vscode\extensions\mvextensions.mvbasic-2.1.2\client\out\extension.js:1:290378)
    at c:\Users\mikew\.vscode\extensions\mvextensions.mvbasic-2.1.2\client\out\extension.js:1:290746
    at Object.<anonymous> (c:\Users\mikew\.vscode\extensions\mvextensions.mvbasic-2.1.2\client\out\extension.js:1:290755)
    at Module.u._compile (c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\loader.js:4:1316)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1155:10)
    at Module.load (internal/modules/cjs/loader.js:982:32)
    at Module._load (internal/modules/cjs/loader.js:823:14)
    at Function.f._load (electron/js2c/asar_bundle.js:5:12913)
    at Function.n._load (c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:113:28606)
    at Function.b._load (c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:113:25193)
    at Function.h._load (c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:103:60406)
    at Module.require (internal/modules/cjs/loader.js:1006:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Function.r [as __$__nodeRequire] (c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\loader.js:5:101)
    at w._loadCommonJSModule (c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:113:26603)
    at w._doActivateExtension (c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:99:12894)
    at w._activateExtension (c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:99:11867)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)

[itsxallwater]

Have picked this up in the background to run package updates and test. Note there's another thread running and describing this error message:

(node:8304) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `Code --trace-deprecation ...` to show where the warning was created)
c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\bootstrap-fork.js:5
filesize is active
c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\bootstrap-fork.js:5
Looking for parseable documents...
c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\bootstrap-fork.js:5
Found no documents
c:\Users\mikew\AppData\Local\Programs\Microsoft VS Code\resources\app\out\bootstrap-fork.js:5

It appears that error is being tracked in the VS Code repo itself (see microsoft/vscode#136874)

[itsxallwater]

Generated a 2.1.3 build locally with updated packages but no dice. It looks (and the call stack above suggests) our issue to be related to sync-rpc and sync-request which are direct and indirect dependencies of the RestFS stuff in the client package. They are pretty dated and not recommended for prod use at this point so I'll take a look at subbing them out. CC @pschellenbach since I think you had worked on that part originally.

[pschellenbach]

Sorry to hear updating packages did not help. sync-request seemed like a nice package at the time. Too bad its not updated. There are lots of promise-based HTTP request packages available, but the code, as-written, is async calling sync, so a sync request is ideal. Maybe something like simple-get would not be too difficult to convert to? Interesting that github for sync-request or sync-rpc do not show any security vulnerabilities, so I wonder why its causing a problem with VSCode?

[itsxallwater]

Valid question. Also curious if we can lazy load that in as it should only really impact if someone is trying to use the RestFS stuff. In the instance of building and running the language server for intellisense and language definition, that part is completely unrelated.

[itsxallwater]

Well I can confirm that subbing out sync-request in the RestFS implementation allows the extension to load okay. If anyone is using it for basic intellisense and language definition stuff here's a pre-release copy that you can install on current VS Code and be okay. The RestFS stuff isn't quite working so if you're needing to use that piece for connectivity to a server you're still better off staying on the previous VS Code release for now.

REDACTED

[itsxallwater]

Kudos to @pschellenbach we have an update to the extension working now with latest VS Code and with the RestFS code. We're working to cleanup for a publish to the marketplace but here's a downloadable and installable copy for the time being if anyone needs. This'll also address an issue with Restricted Mode in VS Code blocking the Extension from being enabled when loading up in certain cases.

REDACTED

[itsxallwater]

Latest beta build.

REDACTED

[itsxallwater]

Getting closer to release but still a few things to iron out:

1. Saving a workspace closes the connection and rest server on the AccuTerm side
2. Saving new records (writeFile) returns a 404 (saving updates to existing records works)

[itsxallwater]

1. Saving a workspace closes the connection and rest server on the AccuTerm side

Not completely accurate, it's only if you "Save Workspace As...". VS Code will complete the save, call the deactivate hook for the current instance of VS Code, and then launch a new instance with that newly saved Workspace open. Our problem is that we call RestFS' logout during deactivation so by the time the new instance is opening, the AccuTerm RestFS server has stopped listening. This is ultimately caused by the fact that we launch VS Code and AccuTerm's RestFS server from the AccuTerm side, and we aren't exposing a way for VS Code to ask a remote AccuTerm/RestFS server to initialize a connection. That coupled with the fact that VS Code will not wait during deactivation--the instance destruction has already begun--so there's no real opportunity to check on the type of action before invoking logout.

A bit of a chicken/egg thing. My hunch is we'll move forward with logout on deactivation and call out that for AccuTerm/RestFS users you'll want to stick with the workspace that is generated for you. That, or, make it an option in the extension so people can choose.

[itsxallwater]

Went with making it an option, MVBasic.RestFS.AutoClose. Default is false. Attached is an updated copy of 2.1.3. Worked like a charm in testing.

REDACTED

[itsxallwater]

2. Saving new records (writeFile) returns a 404 (saving updates to existing records works)

Have a fix for this too, working on an adjacent issue with createDirectory and then will update here.

[itsxallwater]

Latest updates w/ fixes for writeFile and rename. Verified delete is working. Last issue I can see is still with createDirectory and that has to do with how things are structured in _stat. CC @pschellenbach would be great to have you put eyes on that in particular next.

Sort of residual but we'll have to re-think non-200 response code handling, you can see I made one adjustment there already for 404s in _stat which was related to why writeFile was having issues.

mvbasic-2.1.3.zip

[itsxallwater]

Would also be great to have other people put this through its paces if possible, cc @kpowick @mail2lawi @dthiot please and thanks :)

[dthiot]

Mike Wright, You rock!! I have already downloaded the source. Now if I can just get some time to “put eyes on it”. Dick From: Mike Wright ***@***.***> Date: Friday, January 21, 2022 at 5:44 PM To: mvextensions/mvbasic ***@***.***> Cc: Dick Thiot ***@***.***>, Mention ***@***.***> Subject: Re: [mvextensions/mvbasic] VS Code 1.62 breaks the extension. Downgrade to 1.61 (Issue #162) Would also be great to have other people put this through its paces if possible, cc @kpowick<https://github.com/kpowick> @mail2lawi<https://github.com/mail2lawi> @dthiot<https://github.com/dthiot> please and thanks :) — Reply to this email directly, view it on GitHub<#162 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACOODL2PTIWWG7TFXB2GZSDUXHVVPANCNFSM5JLHCH6Q>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[itsxallwater]

@pschellenbach fixed up a few other things and we think this is ready to go. Will be publishing shortly.

[itsxallwater]

This is live, tested again and confirmed! Thanks for hanging tough all.