Open cdmurph32 opened 1 week ago
We just found out that component export handling failures were never logged and fixed that in https://github.com/wasmCloud/wasmCloud/pull/3060
@cdmurph32 could you test if there's now an error reported if you use wasmCloud from latest main
?
There is now this message in the logs.
WARN wasmcloud_host::wasmbus: failed to serve invocation err=failed to serve `wrpc:http/incoming-handler@0.1.0.handle` invocation
commit ad8aecddaf097ae678518e5b3be681e1cb8b5132
It would be nice if the log could give the same output as wasmtime. These types of errors could be completely dependent on the payload, in this case the size of the payload. It would help debugging production issues.
Since https://github.com/wasmCloud/wasmCloud/pull/3117 is merged, we should be logging the Wasmtime error as well, could you confirm that all the output you expect is now available in latest main
?
You should now see up to two log statements on errors here (https://github.com/wasmCloud/wasmCloud/pull/3117/commits/6ab5521e69d235b15b79b66aea8035f260114478)
Affected project(s)
Describe the bug
Nothing is logged If a component hits a MemoryOutOfBounds error.
Steps to reproduce
-z stack-size=2097152
from https://github.com/cdmurph32/pdf-text-example/blob/main/Makefile#L15print_pdf_text
https://github.com/cdmurph32/pdf-text-example/blob/main/pdf_text.c#L230, this doesn't work for different reasons.curl -X POST --data-binary "@pdfio/testfiles/testpdfio.pdf" localhost:8080
to hit a MemoryOutOfBounds errorExpected behavior
I expect the an error to be in the wasmcloud logs.
Environment
Screenshots / Logs / Additional context
No response