A failed test on wasmJs target produces an error t...

# kotest

[Piotr Krzemiński]

A failed test on wasmJs target produces an error that is hard to track wrt. which test actually fails: https://github.com/krzema12/kaml/actions/runs/9437748515/job/25993965918?pr=3. Is it a known issue?
CC @Adam S

[Piotr Krzemiński]

FTR, failing in this PR: https://github.com/krzema12/kaml/actions/runs/9437748515/job/25993965918?pr=3

[Emil Kantis]

@Oliver.O might know

[Oliver.O]

Is this about the difficulty of obtaining relevant information from the stack trace like in this report?

[Piotr Krzemiński]

Kind of, yes

[Oliver.O]

For the record: The above has been caused by K/Wasm not throwing out-of-bounds exceptions (https://youtrack.jetbrains.com/issue/KT-59081/) unless -Xwasm-enable-array-range-checks is provided.

[Piotr Krzemiński]

thanks, I figured this one out! the reporting is a separate problem then

[Oliver.O]

Yep. Do you see anything Kotest could do better here?

[Piotr Krzemiński]

I'd expect a normal stack trace I could navigate to find the offending test, is it at all possible? do we have any source maps in Wasm?

[Oliver.O]

The weird stack traces are a limitation of Kotlin/Wasm. Their appearance is unrelated to the test framework, which means you'd see them with kotlin-test as well. Source maps in Wasm are produced by default and can be used to debug in the browser, but source maps won't help with stack traces in test logs.

[Piotr Krzemiński]

@Oliver.O do you know if there's a ticket to make stack traces better in Kotlin/Wasm?

[Oliver.O]

I don’t know for sure. I could not find one with a quick search. The current format seems to be described here. You’d surely get definitive answers on #webassembly.