Internal error: resolution record for symbol {name} indicate

Error message

Internal error: resolution record for symbol {name} indicates non-function resolution {resolution:?}

What it means

This panic fires in generate_stub_function when the linker's resolution record for a requested import symbol points to something that is not a function, while the import being populated expects a function (and a stub function is being generated for it). The linker maintains a symbol->resolution map; if a caller (populate_imports_from_link_state / populate_imports_from_linker) tries to bind a function import against a non-function resolution (e.g. a global or memory), the internal invariant is broken and it aborts. It indicates corrupted or inconsistent linker state, not a problem with the user's WASI usage per se.

Source

Thrown at lib/wasix/src/state/linker/instance_group/imports.rs:676

                                        ?requesting_module,
                                        name,
                                        ?resolved_from,
                                        "Updating linker state with this resolution"
                                    );

                                    *resolved_guard = Some(Some(func.clone()));
                                    linker_state.symbol_resolution_records.insert(
                                        resolution_key,
                                        SymbolResolutionResult::Function {
                                            ty: func.ty(&store),
                                            resolved_from,
                                        },
                                    );
                                }

                                func.clone()
                            }
                            Some(resolution) => panic!(
                                "Internal error: resolution record for symbol \
                                {name} indicates non-function resolution {resolution:?}"
                            ),
                        }
                    }
                    Some(None) => return Err(mk_error()),
                    Some(Some(ref func)) => func.clone(),
                };
                drop(resolved_guard);

                let mut store = env.as_store_mut();
                func.call(&mut store, params)
                    .map(|ret| ret.into())
                    .map_err(flatten_runtime_error)
            },
        )
    }
}

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

Verify the symbol name in the module's imports matches a function-kind definition in the linker (define_func, not define_global/memory)
Rebuild LinkerState from a single Linker instance; do not share resolution records between linkers or reuse stale link state
Check for typos/collisions where the same name was defined twice with different kinds; the last definition wins in the map
If it persists, capture the symbol name and resolution variant from the panic message and report it as a linker bug with a reproducer

Example fix

// before: same name registered as a global, module imports it as a func
linker.define("env", "callback", Func::new(...));
linker.define("env", "callback", Global::new(...)); // overwrite -> non-function resolution
// after
linker.define("env", "callback", Func::new(...)); // keep kinds consistent per symbol

Defensive patterns

Strategy: validation

Validate before calling

fn assert_function_resolution(state: &LinkerState, name: &str) -> bool {
    matches!(state.lookup(name), Some(Resolution::Function(_)))
}
// call before populate_imports_* for every function import
if !assert_function_resolution(&state, "env::callback") {
    return Err(format!("{name} is not registered as a function"));
}

Type guard

fn is_function_resolution(r: &Resolution) -> bool {
    matches!(r, Resolution::Function(_))
}

Prevention

Register each import name with exactly one definition kind (func stays func)
Never share LinkerState between Linker/InstanceGroup instances
Deduplicate symbol definitions to avoid kind overwrites
Log the resolution kind for each symbol before populating imports

When it happens

Trigger: Instantiating a module whose function-type import resolves to a symbol that was registered in the linker state as a global/memory/table; calling populate_imports_from_link_state or populate_imports_from_linker with a LinkerState whose symbol resolutions were mutated or built by a different linker instance.

Common situations: Mixing resolutions across multiple Linker/InstanceGroup instances; a host-defined symbol name shadowed by a non-function definition; bugs in custom dlopen-style dynamic linking flows where symbols were recorded with the wrong resolution kind.

Related errors

AI-assisted analysis of wasmerio/wasmer@8c4b9ee9d3 (2026-09-01). Data as JSON: /api/errors/8ce9f227d2bed227. Report an issue: GitHub.