[CM async] panic performing blocking operation during core start function

This panic is a classic async-runtime boundary violation: a blocking host operation is being triggered while a core start function is executing in a context that must remain non-blocking. In component-model async execution, start functions run during instantiation, and if imported host behavior tries to wait, block, or re-enter the executor incorrectly, the runtime panics instead of allowing unsafe progress.

Understanding the Root Cause

The failure happens because a core module start path is expected to be safe to execute during instantiation, but the imported behavior used by that module attempts a blocking operation. In a component model async environment, host calls may be adapted into futures, scheduled tasks, or runtime-managed state machines. A start function, however, executes at a sensitive time: the instance is not fully available for arbitrary suspension, and the runtime often forbids anything that could block the current thread or require nested executor progress.

In practice, the panic usually comes from one of these patterns:

• A host import invoked by the core start function performs a synchronous wait on async work.
• The runtime detects a block_on-style call from within an already-running async executor.
• A start function indirectly triggers resource initialization that uses locks, condition variables, or async-to-sync bridging in an unsupported way.
• The component async machinery marks that call site as non-blocking-only, but the host implementation violates that contract.

Why the runtime panics instead of just waiting is important: allowing blocking at this point can deadlock the executor, stall instance creation, or violate internal scheduling assumptions. The panic is therefore a protective failure that exposes an invalid interaction between core start semantics and async host behavior.

The WAST in the issue is effectively constructing a scenario where a core module imports host functionality and triggers it during startup. If that host function waits on async completion, sleeps in a forbidden place, or performs a runtime-blocking operation, the engine aborts with the panic described.

Step-by-Step Solution

The fix is to ensure that core start functions never perform blocking host work. Move the work out of start, split initialization into explicit phases, or convert the host boundary so startup remains purely non-blocking.

1. Identify whether the blocking happens directly or indirectly

Inspect the imported function used by the core module during instantiation. Look for patterns such as synchronous waits, nested runtime entry, mutex contention with async tasks, or filesystem/network calls wrapped in blocking helpers.

// Problem pattern inside a host import used by core start logic
fn imported_wait() {
    // Any sync wait inside async-managed startup is suspicious
    runtime.block_on(async_work());
}

If the issue is not obvious, trace the full call chain from the start function into the host implementation.

2. Remove blocking behavior from startup code

If the host import is called during start, make it return immediately or perform only lightweight, non-blocking state setup.

// Better: keep startup-side host logic trivial
fn imported_init_marker(state: &mut HostState) {
    state.initialized = true;
}

This preserves instantiation safety and avoids executor misuse.

3. Move async or blocking initialization into an explicit exported function

Instead of doing real work in the start path, instantiate first and then call an exported function designed for async-safe initialization.

// Core idea:
// 1. instantiate component/module
// 2. call exported init function after instantiation
// 3. await async work there using the supported runtime path

async fn initialize_instance(instance: &MyInstance) -> Result<(), Error> {
    instance.call_init().await?;
    Ok(())
}

This is usually the cleanest fix because it respects the lifecycle: instantiation remains synchronous/non-blocking where required, while real initialization happens later in a fully async-capable context.

4. If host work must happen early, make it non-blocking and state-driven

When startup must trigger something, record intent instead of waiting for completion.

struct HostState {
    init_requested: bool,
}

fn imported_request_init(state: &mut HostState) {
    state.init_requested = true;
}

async fn process_deferred_init(state: &mut HostState) {
    if state.init_requested {
        async_work().await;
        state.init_requested = false;
    }
}

This pattern works well when adapting legacy host code to the component model.

5. Avoid nested executor entry

If your host implementation uses Tokio, async-std, or a custom executor, do not call blocking runtime entrypoints from code that may already be running inside the executor.

// Avoid this in host functions reached from async-managed execution
fn host_fn() {
    tokio::runtime::Handle::current().block_on(async {
        do_work().await;
    });
}

Prefer propagating async upward so the caller awaits naturally in a supported context.

// Preferred shape
async fn host_fn_async() {
    do_work().await;
}

6. Restructure the WAST test to reflect valid lifecycle behavior

If the issue is in a conformance or regression test, separate the action performed during component construction from the action that actually waits. The test should instantiate successfully, then invoke the behavior in a later call where async execution is allowed.

(component
  ;; instantiate safely
  ...
  ;; expose an exported function for post-instantiation work
)

The exact syntax depends on the final component/test layout, but the principle is consistent: do not force blocking behavior from core start.

7. Add a regression test that asserts no panic occurs during instantiation

Once fixed, validate both phases independently:

• Instantiation completes without panic.
• Deferred initialization runs in a valid async context.
• Errors are surfaced as traps or host errors, not runtime panics.

#[tokio::test]
async fn instantiation_does_not_block() {
    let instance = instantiate_component().await.expect("instantiation should succeed");
    instance.call_init().await.expect("init should succeed");
}

Common Edge Cases

• Indirect blocking through libraries: your code may look async-safe, but a dependency may use synchronous I/O, thread joins, or hidden blocking locks.
• Lazy initialization: a harmless-looking first call may trigger one-time setup that blocks, such as loading metadata or creating shared state.
• Mutex misuse: holding a standard mutex while invoking async-aware host code can deadlock or panic under executor constraints.
• Cross-runtime integration: mixing different async runtimes can cause nested polling or unsupported blocking behavior even if each side appears correct in isolation.
• Trap vs panic confusion: expected guest failures should become traps or structured errors. A panic usually signals a host/runtime contract violation, not a guest-level error.
• Resource handles during start: creating or touching async-managed resources in start may fail if the resource system expects a fully initialized instance context.

FAQ

Can I ever call host imports from a core start function?

Yes, but only if those imports are guaranteed non-blocking and do not require suspension, nested executor entry, or deferred async completion. Keep them side-effect-light and startup-safe.

Why does this panic instead of returning a normal trap?

Because the failure is typically in the host/runtime execution model, not in guest program semantics. A trap represents a guest-visible runtime condition; a panic here usually indicates an internal contract was violated by performing forbidden blocking work.

What is the safest architectural fix?

The safest fix is to remove meaningful work from the start function and expose an explicit initialization/exported call that runs after instantiation in a proper async context. That approach is easier to test, easier to reason about, and avoids lifecycle deadlocks.

In short, the issue is not that async work exists, but that it is being forced through the wrong phase of execution. Treat core start as a strictly limited initialization hook, keep it non-blocking, and move any waiting, I/O, or async coordination into a later call boundary designed for it.