eclipse-cdt-cloud / vscode-trace-server Goto Github PK

Trace Server: Start (if stopped) command to trace server should be renamed to Trace Server: Start. The add-on if stopped is not relevant for the user and requires the user to know implementation details to understand. Instead the error messages for failing start command should indicate why the trace server couldn't be started.

The version we are using has a license that's not approved by the Eclipse Foundation:
https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/12939#note_1703449

We should update to v8.43.0 or later

This extension (vscode-trace-server) is a companion to extension eclipse-cdt.vscode-trace-extension (Trace Viewer for VSCode) and depends on it.

At activation, this extension obtains a reference to the trace viewer's exported API object, and uses it to provide helper functionality. This work well normally, but there may be a corner-case that we should handle better: if/when the Trace Viewer extension becomes disabled, we probably should not use its API object any more, and if/when it becomes enabled again, we should obtain a fresh API object and redo the activation steps.

One scenario where the above might happen (to be confirmed) is when the Trace Viewer extension is updated to a new version.

As a starting point, here is how it seems the built-in vscode.github extension monitors the "enablement" of vscode.git-base it depends-on, and "refreshes" its API object when needed:

The trace server is not stopped when running this extension with vscode/codium remote. I have noticed this behaviour in local install as well, but very rarely.

I did some investigation and with some logging (to file) I was able to confirm, that the deactivate() method of the vscode-trace-server is being called. However, the call to tree-kill(pid) has no effect. More investigation needed to fix stopping the trace server on exit.

I did some more digging to figure out what's going on. I think what's happening is that VsCode exits before the treeKill() command is executed. treeKill() spawns external processes to get all the children pids from the parent pid of the trace server launcher. It reads the stdout of the command ps -o pid --no-headers --ppid $ppid and then uses the collected list of pids to call process.kill on it. This is done in a callback, but the parent VsCode application already exited and the hence the no process is killed. I was able to make it work by adding some async/wait/timeout call to delay the execution.

Please note that this can also happen in the local case. I guess, that the shutdown of a local VsCode application takes longer than closing the remote processes.

Originally posted by @bhufmann in eclipse-cdt-cloud/vscode-trace-extension#173 (comment)

Consider initializing support for an implementation based on [1] below.

• This would be alongside the currently proposed #3, which is mainly Linux-based [2].
• Below [3] might also have to be considered eventually or alongside [1,2].

[1] https://github.com/gitpod-io/openvscode-server#docker
[2] https://github.com/gitpod-io/openvscode-server#linux
[3] https://github.com/gitpod-io/openvscode-server#securing-access-to-your-ide

Node 16 end-of-life was last September 11th.

This repo will need a quick update, to use node 18 (currently 16.x). Potential references to node version:

• GitHub workflows: add at least node 18 in the "matrix" (we may keep 16 for now).
• package.json "engines.node" version ranges may need updating. e.g. ">=16 <=20 " could work for now
• dockerfiles
• documentation, e.g. README, guides

At a minimum, a 3PP license check needs to be performed before any release of an Eclipse Foundation project component, but ideally it should be done for each PR before merging, to catch 3PPs with incompatible or unclear licenses as early as possible.

We have been working on a standalone nodejs wrapper for Eclipse Foundation's dash-licenses, that can be used to easily add 3PP license checks in JS/TS repositories:

https://github.com/eclipse-dash/nodejs-wrapper

We will soon have its first release to npm, and thereafter it can be easily be added as a devDependency and used in this repo and others in this organization.

This will make it much easier to install for the end-users

When the extension doing a heath check (HTTP query) to the server to check if the server is available it uses hard-coded URL http://localhost:8080. Since it's possible to change the port on the server, the client site needs to be configurable as well.

When using this extension with vscode-trace-extension, use the URL from that extension.

rejected promise not handled within 1 second: Error: command 'serverStatus.started' not found
extensionHostProcess.js:104
stack trace: Error: command 'serverStatus.started' not found
at e.CommandService._tryExecuteCommand (vscode-file://vscode-app/usr/share/codium/resources/app/out/vs/workbench/workbench.desktop.main.js:1515:15998)
at e.CommandService.executeCommand (vscode-file://vscode-app/usr/share/codium/resources/app/out/vs/workbench/workbench.desktop.main.js:1515:15880)

The trace server URL is configured as a preference, contributed in the vscode-trace-extension:

For the end-user it may not seem unreasonable to add a slash at the end of the URL, but when that is done, it results in a timeout, when attempting to start the trace server. This is because we currently add another slash, when resolving the complete TSP API URL, as part of the health-check that confirm the server was succeessfully started:

It would be easy enough to check for the presence of the slash at the end of the server URL, and not add a second onie if already present, as it's done in the trace viewer: