Troubleshooting

When troubleshooting deployments with Cosmonic Control, your first step will typically be to check your wasmCloud host logs.

Host logs

The logs for wasmCloud hosts are available through the Kubernetes API (and tools that use the API like kubectl). They can be accessed via the host group service for the host in question.

In the default installation described on the Get Started page, a wasmCloud host is running in the default host group and the cosmonic-system namespace, so the kubectl command to access host logs would look like this:

kubectl logs service/hostgroup-default -n cosmonic-system

Component returns 500 with waitable cannot be used synchronously while added to a waitable set

A WASI P3 component traps on the first request that suspends, and the host log shows wasm trap: waitable cannot be used synchronously while added to a waitable set followed by failed to invoke component: pooled instance dropped the request.

Since v0.12.2 the host runs on Wasmtime 48, which traps on a bug in the async runtime that wit-bindgen 0.58 and earlier generate when the inter-task-wakeup feature is on. Rebuild the component on wasip3 0.9.0 and wit-bindgen 0.62.0. See WASI P3 components built on wit-bindgen 0.58 or earlier must be rebuilt for how to check a component and the exact dependency change.