Open artemii235 opened 1 year ago
I have two ideas on how to catch the logs and (most complex problem) to match them to a corresponding MmCtx
instance:
Both ideas require changing the wasm test runner or using a custom one. I'll try to investigate what can be done.
@sergeyboyko0791 This seems not easy. As this task is not a priority, you can postpone it indefinitely 🙂 Maybe we will have more ideas after some time.
I have also a workaround to implement the 1. point https://github.com/KomodoPlatform/atomicDEX-API/issues/1634#issuecomment-1411841050:
We can implement a procedural macro #[mm2_wasm_test]
that will do the following:
#[mm2_wasm_test(no_parallel)]
not specified), manages to run the only this test at the same moment. This could also clear the static log registry, so we can catch the logs recorded by log::info
macro.#[mm2_wasm_test(timeout = 120)]
.
Currently, we don't have the way to detect the tests that were stuck. WASM bindgen runner doesn't provide such info, so I believe it could be very helpful.@artemii235 what do you think?
For example, I had to use
log_tag!
instead ofinfo!
here: https://github.com/KomodoPlatform/atomicDEX-API/commit/a53daabed076a0481f5bc18858b9239d3ccd3919#diff-608240539630bec8eb43b211b0b74ec3580b34dda66e339bac21c04b1db6da43R272-R277.@sergeyboyko0791 Could you please tell if we can catch
info!/...
output in WASM tests, and how hard will it be?