Seeing as there is no way to memory debug whats happening inside the wasm.
we are reliant on debug outputs, forced panics and function returns to determine what the rust code is doing.
Many runtime error responses are also “unknown error”.
This makes working with complex zomes slow and often challenging work.
As far as I understand, the only serious tool we have for testing zomes is tryorama… ?
There a few things on my wishlist…
First would be to use a custom log function that wraps a macro which tryorama would pick up in INFO mode … this would speed up development because we wouldnt have to wade through a mass of unrelated debug statements from rust or tryorama
i believe this is related to how wasmer handles the errors we return (it immediately bails), and currently we’re probably a bit aggressive about aborting and winding back the wasm when we could be returning errors such as “failed to delete an element that we cannot get from the network” to be handled by wasm
in this case the host would be reporting something like “host function completed successfully with a failure to do X” so that wasmer continues executing but then the guest needs to handle that failure
this means the guest will need to be more explicit about handling these cases, so probably a bit more boilerplate, but overall i’m expecting this to be less work because the error handling becomes explicit rather than getting swallowed by wasmer somewhere
depends what you mean by ‘serious tool’ - you can also write rust unit tests for the wasm itself rust tests that drive the ribosome/conductor (e.g. core doesn’t use tryorama to test itself)
i’m currently looking at integrating the rust tracing crate more deeply with the HDK, e.g. including line numbers etc. tracing the most common issues (e.g. bytes that fail to deserialize), creating a tracing span for #[hdk_extern]
tracing supports filtering based on metadata associated with events/spans so i’m expecting that it will be possible to filter logs down to the specific extern and verbosity level that you need, at least from rust
for the tryorama side of things cc: @maackle maybe
you can disable all logs from the holochain binary with RUST_LOG and filter to what you need out of wasm with WASM_LOG - as per rust tracing crate conventions
this is merged, @nphias it should be possible to disable conductor logs with RUST_LOG and enable WASM_LOG (set to debug by default) and use the tracing crate inside wasm, as of latest develop
next i’ll change the error handling in host calls to return the error back to the wasm to be handled rather than short circuiting
Tryorama times out on attach_app_interface with not much additional information on what went wrong.
**15:58:54 [tryorama] error: Test error: 'Error: Timed out in 15000ms: attach_app_interface\n' +
' at Timeout.<anonymous> (/home/ubuntu/code/storage/tests/node_modules/tryorama/node_modules/@holochain/conductor-api/src/websocket/common.ts:16:14)\n' +
' at listOnTimeout (internal/timers.js:549:17)\n' +
' at processTimers (internal/timers.js:492:7)'
not ok 1 Test threw an exception. See output for details.**
So since hdk v0.0.100 and the removal of dna_utils the develop branch has been a bit “stuck” in that the tooling pack dnas was not ready yet. Today it is, but both the conductor-api repo and the tryorama repo are still having unmerged PRs.
I’m hoping as everything gets smoothed out to fix this repo so that we can all be happy and on track with the latest holochain again.
Sounds great, came across that repo today and had the same idea . Similar instructions can also be found in the holochain repo. One of those instructions perhaps can be removed in the process. It would be great to establish a single “source of truth” with build instructions for sort of… the latest stable build where holochain plus tooling works together.