IDE logging not working when opening cloud project

[MichaelMauderer]

Discord username

No response

What type of issue is this?

Permanent – Occurring repeatably

Is this issue blocking you from using Enso?

• Yes, I can't use Enso because of this issue.

Is this a regression?

• Yes, previous version of Enso did not have this issue.

What issue are you facing?

When opening a cloud project in the IDE (started with ./run ide watch --backend-source release --backend-release latest --skip-wasm-opt --ide-option -debug.dev-tools=true --ide-option -debug), there is no debug output in the dev console (e.g., logs from calls to console_log!).
It works fine when opening a local project.

Expected behaviour

Log output should appear.

How we can reproduce it?

• Run ./run ide watch --backend-source release --backend-release latest --skip-wasm-opt --ide-option -debug.dev-tools=true --ide-option -debug
• Switch to cloud projects in the dashboard
• Open a cloud project
• Watch the dev console

Screenshots or screencasts

Local project output (with IDE log output)

Cloud project output (missing IDE log output)

Logs

No response

Enso Version

develop

Browser or standalone distribution

Standalone distribution (cloud project)

Browser Version or standalone distribution

standalone

Operating System

Linux

Operating System Version

No response

Hardware you are using

No response

[MichaelMauderer]

I will be doing some more investigation into this as it is blocking my current task.

[somebody1234]

this is probably the cause:

enso/app/ide-desktop/lib/dashboard/src/authentication/src/dashboard/components/ide.tsx

Lines 106 to 111 in cfb2f29

	// The URL query contains commandline options when running in the desktop,
	// which will break the entrypoint for opening a fresh IDE instance.
	history.replaceState(null, '', new URL('.', originalUrl))
	await runNewProject()
	// Restore original URL so that initialization works correctly on refresh.
	history.replaceState(null, '', originalUrl)

it was introduced to work around issues with the cloud frontend, but i can see if they're no longer an issue

[vitvakatu]

@somebody1234 @sylwiabr can we prioritize this task, as it is blocking @MichaelMauderer?

[somebody1234]

took a look at it earlier but couldn't get the [FRP] logs for some reason (even on local backend). i have -debug.dev-tools -debug both on so no idea what's going on

[MichaelMauderer]

took a look at it earlier but couldn't get the [FRP] logs for some reason (even on local backend). i have -debug.dev-tools -debug both on so no idea what's going on

To get some logs, you will also need to enable them somewhere in the code. For example here

enso/app/gui/view/graph-editor/src/component/visualization/container.rs

Line 128 in cfb2f29

ensogl::define_endpoints! {

You can replace

ensogl::define_endpoints! {

with

ensogl::define_endpoints! { [TRACE_ALL]

[MichaelMauderer]

@somebody1234 It appears that something is deeply broken here: just entering console.log("Hello") does not produce the expected output in a cloud project. (It does as it should in a local project).

[MichaelMauderer]

I'm somewhat stuck debugging this further, as it seems when going into cloud mode, the IDE no longer loads local scripts, but an index file from the CDN, which I cannot edit/change.

Maybe the router is not correctly initialized, but I've been unable to make it work with showLog.
It also seems that the console when trying to access it from where it is stored within the router (this.console["log"]) does not produce output. Again, this does work in the non-cloud mode for the IDE.

[somebody1234]

while it does load an index.js.gz file, i think it's not actually used, as appRunner is being used, which does not run the index.js.gz entrypoint. i have the code that loads that file disabled locally but can still repro

to test without index.js.gz locally, you can try changing this line to if (true):

enso/app/ide-desktop/lib/dashboard/src/authentication/src/dashboard/components/ide.tsx

Line 96 in cfb2f29

if (backend.type === backendModule.BackendType.local) {

[somebody1234]

ok upon closer inspection, many of the logs are there - under this collapsed group:

so i think one root cause (if not the root cause) is that this group is not being closed...

upon thinking a bit, maybe it's a race condition - groupEnd might incorrectly be eaten by router.ts, which would explain why the group swallows every log after that.

on a side note, i'm getting weird errors instead of frp logs:

[MichaelMauderer]

Argh. Yes, with that group open, also console.log and console.warn produce output.

I'm also not getting the FRP logging, but maybe that is some other interaction with the open group.

[wdanilo]

The root issue might be caused by the group not being closed indeed.

The question is if this is the only issue. If fixing it will not resolve all issues, I have yet another suspicion here – we have something that is called LogManager or something like that. Basically, it gathers logs in one place and allows function showLogs to flush them. After this fn is called, all subsequent logs land in the console. What could happen here is that cloud team might initialize this log manager twice (to be checked). If that happens, then calling showLogs would flush all logs ... from one log manager to another, but not to console.

[somebody1234]

but as mentioned above, opening the collapsed groups shows the missing logs, so not 100% sure that's the case

[wdanilo]

@somebody1234 to be checked if this happens on Michaels end as well. The thing is that in your example these were errors and I'm not sure when they were emitted. This might be the same case as at Michaels end, or might be another (that also needs to be fixed). I posted additional possible theoretical explanation for missing logs, but it is probable, that everything is caused by the group not being closed.

I think I expressed my thoughts wrong in my previous answer - I'll edit it, sorry for that!

[somebody1234]

see michael's comment right above yours - that's what i'm referring to
i left out that console.logs were working after the group is expanded so it may have been unclear

[wdanilo]

@somebody1234 Oh, I'm blind. I totally missed Michaels comment above ... sorry about it!

[somebody1234]

i think i found the reason why the group is not being ended:

(console.log(this.receivedBytes, this.totalBytes))

whereas it lines up perfectly on the local backend:

enso/lib/rust/ensogl/pack/js/src/runner/wasm/loader.ts

Lines 368 to 370 in cfb2f29

	isDone() {
	return this.receivedBytes == this.totalBytes
	}

not quite sure why it's overshooting though...

i tried disabling the service worker in case that did something funky with the content-size or something but that didn't make a difference

[wdanilo]

Oh, wow, that's interesting! Could you please check if cloud is reporting the size correctly? Anyway, the code should use > instead of == anyway, as this is just less error prone. Good finding, thanks @somebody1234 !

[somebody1234]

on a tangent, it might be nice to replace the download speed with.. something like a moving average? like, downloadSpeed = downloadSpeed * 0.7 + newlyMeasuredDownloadSpeed * 0.3 - because on both local backend (backed by ssd/hdd) and remote backend the download speed may vary by an order of magnitude (or even two!)

[MichaelMauderer]

i think i found the reason why the group is not being ended:

Changing the check in isDone to <= makes the group close and some logs appear.
But … not all logs from the IDE. Neither the FRP logs with the console_log! macro, neither with an elevated error! macro, nor other logging that've tried to add.

EDIT: It looks like the IDE is using a WASM file from a CDN instead of the local one.

[MichaelMauderer]

I think that is the true source of my original problem here: when starting a cloud project the IDE local IDE files are not used, and we are essentially running a different IDE version.

[somebody1234]

yeah... of course 🤦 totally slipped my mind that the change to enable the frp traces produces a different wasm bundle.

@MichaelMauderer not sure whether it's possible to fix your original problem in that case... i think a reasonable (?) workaround may be to change this:

enso/app/ide-desktop/lib/dashboard/src/authentication/src/dashboard/components/ide.tsx

Line 84 in cfb2f29

wasmUrl: `${assetsRoot}pkg-opt.wasm`,

to just 'pkg-opt.wasm' so that it always loads the local copy rather than the cloud one

[somebody1234]

@wdanilo actually, is the dashboard's ide runner currently implemented incorrectly? maybe only the latest version of pkg.wasm+pkg.js+shaders need to be used? at least i think that's been the case for the desktop IDE all along, right?

backwards incompatibility might be an issue, but that only applies to the json+binary language server endpoints, right?
(not that it makes backcompat less of an issue, just trying to figure out why the desktop ide doesn't need different builds of pkg.wasm)

[wdanilo]

@somebody1234 pkg.wasm, shaders, etc are highly tied to the engine version, as GUI (both backend and visuals) are using specific backend APIs and adjustments. So if we are choosing a specific backend version, we need to use the compatible frontend version as well. We MIGH be able to lift this restriction in the future, but then we would need to very carefully design process in IDE to make it backward compatible – I'm not sure if that would ever be beneficial TBH even in long-term future though. So, if you are opening an engine version, we need to have IDE version bound to the engine version.

The local IDE uses bundled pkg.wasm and shaders. Opening different engine version locally is NOT guaranteed to work and this is mainly for testing / debug purposes, not for real work, as it might break on clients projects.

[farmaazon]

@wdanilo but that means we might want to download older IDE wasm also for local project? Currently, we always open the bundled wasm, even if the project was created for older engine version.

[MichaelMauderer]

yeah... of course 🤦 totally slipped my mind that the change to enable the frp traces produces a different wasm bundle.

@MichaelMauderer not sure whether it's possible to fix your original problem in that case... i think a reasonable (?) workaround may be to change this:

enso/app/ide-desktop/lib/dashboard/src/authentication/src/dashboard/components/ide.tsx

Line 84 in cfb2f29

wasmUrl: `${assetsRoot}pkg-opt.wasm`,

to just 'pkg-opt.wasm' so that it always loads the local copy rather than the cloud one

I had tried that, unfortunately that does not seem to work. I also tried replacing other assets with the local ones, but no luck. I'll have to double-check what the difference is to local projects.

Uncaught (in promise) LinkError: WebAssembly.instantiate(): Import #239 module="wbg" function="__wbg_offsetTop_432bdb615524a5f0" error: function import requires a callable

[MichaelMauderer]

@wdanilo I’ve got the same question as Adam, but even more: do we then need to start keeping an up-to-date bug list of “known issues” per IDE/engine version? If we use old IDE versions for old projects, those will keep old bugs around, and we will need to deal with those potentially being filed over and over again.

[farmaazon]

@wdanilo @MichaelMauderer @somebody1234 let's continue discussion in https://github.com/orgs/enso-org/discussions/6762#discussioncomment-6090645

GitHub

Language Server API · enso-org · Discussion #6762

When I was discussion with @Frizi the issue #6715, we discovered several points about Language Server API to be discussed broader @4e6 @hubertp : What widgets needs to know The widgets need to know...

[JaroslavTulach]

If we use old IDE versions for old projects, those will keep old bugs around,

You can always backport the most critical bugfixes and instruct the cloud to offer the bugfixed version of the old IDE.... one of the 20 API Paradoxes is called "maintenance" and claims that sooner or later every API designer job turns into "sustaining" - welcome to the sustaining team, Michael!

[JaroslavTulach]

While I agree there are some tightly coupled pieces between IDE and engine+stdlibs, I also have questions:

pkg.wasm, shaders, etc are highly tied to the engine version,

How are the shaders related to engine version?

as GUI (both backend and visuals) are using specific backend APIs and adjustments.

I know that visualizations (the JavaScript parts) are shipped with IDE and are tightly coupled with Standard.Visualization library, right @jdunkerley? There is the language server protocol, of couse. But is there something other than these two?

So if we are choosing a specific backend version, we need to use the compatible frontend version as well.

Alas, that's our current situation.

[enso-bot]

E-Hern Lee reports a new STANDUP for the provided date (2023-06-05):

Progress: investigate + implement It should be finished by 2023-06-09.