[BUG]: WASM/Rust layer panics and cannot catch it.

[nadr0]

Describe the bug

When you have a large import/export file the WASM runtime can panic due to some internal issue happening in rust. This will brick the TS workflow because the promise never returns and the logic of the system will not cleanup properly.

This prevents you from executing future KCL files so you cannot switch files or rerun your code.

Steps to Reproduce

Get the KCL files from here, it is two files one that is a massive export.

1. Make a massive file to export
2. Import it into a main.kcl file
3. Wait for the WASM runtime to brick

Expected Behavior

We should be able to gracefully recover from a crashed WASM/Rust run of the AST.

this.isExecuting and some other cleanup calls need to be invoked to properly restore the TS state in the application after the promise for executeAST dies.

Screenshots and Recordings

Desktop OS

Linux

Browser

No response

Version

v0.34.0

Additional Context

It has at least been a bug since v0.30.0

rustwasm/wasm-bindgen#2392

We will be using window.addEventListener('error', (event) => { ... }) to catch a global error since we cannot try catch the error from the executeAST promise it completely dies in that context.

We will need a global error handler that can map some of those runtime errors across the entire application state. It isn't amazing but after pairing with a few devs this is the only thing we could find. When rust panics we cannot catch that error in TS.

Sample error that is being caught with the global handler

[jtran]

I think an example of KCL triggering this is the same as in #4437, but if not, can you post it?

[nadr0]

Yes it is the same one in that post above.

[nadr0]

rustwasm/wasm-bindgen#4095
https://stackoverflow.com/questions/78852367/how-to-re-initialize-a-module-generated-by-wasm-bindgen
rustwasm/wasm-bindgen#3307
nodejs/help#2751

This is proving to be more complicated than expected. There is not a clear method to properly re init the wbindgen code which would clear the old WebAssembly instance.

I spent time trying to catch the error then restore our JS state back to normal to reload a new file in the application but the application still bricks because the old WebAssembly module is still corrupted from that back execution.

The only possible solution I can currently think of is wrapping the import/export of the wasm-lib/pkg/wasm_lib.js file to make it not be cached. This would allow us to reload that file (?)

I don't think dynamic importing will work either due to the last resource I posted saying that a future node.js version will brick it. Using a query parameter to time stamp the file URL can retrigger the entire import but I don't want to implement that if it will break in future node.js versions.