How intriguing Rob.

May I suggest you edit the post and change the language at the top of the CodeSnippet elements so they're set to JavaScript instead of ObjectScript? Or if you prefer, ask me and I'll do it using my DC Moderator powers.

It won't necessarily be the instance name, depending on how the external web server has been set up.

In the intersystems.servers object in your settings JSON you can add a pathPrefix property within the webServer object of your connection definition. In your example:

"intersystems.servers": {
...
    "server1": {
        "webServer": {
            "host": "localhost",
            "port": 443,
            "scheme": "https",
            "pathPrefix": "/instance1"
        }
    },
...
}

Interesting. Based on doc at https://docs.intersystems.com/healthconnectlatest/csp/documatic/%25CSP.D... the common attribute of all the faultily-displaying properties is that they are calculated. Does that hold true for the ones not shown in your screenshot?

Were you logged in as a user with the %All role when you clicked the update link in WebTerminal?

An example is shown in https://community.intersystems.com/post/use-serenji-debug-your-rest-serv...

The Serenji VS Code extension from George James Software supports direct backend debugging of REST endpoints in Caché and InterSystems IRIS.

The debugging features of Serenji require an activation key. We provide free 30-day keys upon request.

John Murray
Senior Product Engineer
George James Software

Maybe you need to sign up on the Columnar Storage Early Access Program at https://gs2022.isccloud.io/#early-access

UnknownUser is normal for the /terminalsocket session.

Does the problem also occur if you start from an incognito/InPrivate instance of your web browser?

Previously you reported that WebTerminal is working OK on another of your InterSystems environments. Is this still the case? Is that one using 4.9.5 yet?

For the one that fails to make the websocket connection I suggest you use F12 in your browser to open Developer Tools, and make sure network tracing is active before you go to the /terminal/ URL to open a WebTerminal. Look at the network trace messages, and compare them to equivalent messages from a different web browser session that connects successfully to WebTerminal on your other environment.

I'm not clear whether WebTerminal ever worked on this InterSystems instance, e.g. with WebTerminal 4.9.3.

Maybe also worth checking what the InterSystems security audit log is showing around the time you fail to connect with WebTerminal. You may need to turn this auditing on, and perhaps enable it for some additional event types.

As long as the XML import compiled the classes, there's nothing else you need to do in order to benefit from the update.

I suggest you stop using WebTerminal for at least 15 minutes, then check in Portal's Web Sessions page (under System Operation) that no /terminalsocket sessions remain.

Next, launch a WebTerminal. Confirm it reports being version 4.9.5. Check that the Web Sessions page shows one /terminalsocket entry. Now close your WebTerminal browser. Refresh the Web Sessions page. The /terminalsocket entry should no longer be there.

WebTerminal 4.9.5 is now available. After updating to this you should no longer see /terminalsocket web sessions hanging around for 15 minutes after WebTerminal browser windows have been closed.

This should help with license starvation issues.

When comparing between an environment that works and the one that doesn't, did you also check the settings of the /terminalsocket application? If not, please do that.

This is probably best handled in the GitHub repository at https://github.com/intersystems-community/webterminal/issues

Are you willing to open a new issue there?

Either way please confirm what URL you are launching WebTerminal at, e.g. http://localhost:57772/terminal/