Related to #1313, but this issue is about missing initialization of _isHostProvided.
When mapping a JS class as an async WIT resource using the --map option, _isHostProvided is not initialized.
In contrast, when using --instantiation, _isHostProvided is initialized correctly.
Even if issue #1313 is fixed, _isHostProvided remains undefined for JS class.
As a result, the following branch is never taken:
if (hostProvided) {
task.resolve([ret]);
endCurrentTask(0, task.id());
return task.completionPromise();
}Actual behavior:
- Since
_isHostProvided is not initialized, hostProvided is always falthy (e.g. undefined)
- The fast-path branch is never taken
- Execution falls through to the driver loop path, which assumes a Wasm-originated subtask
- However, this call does not originate from Wasm, so no subtask is created
- As a result, subtask lookup returns
null or undefined, leading to a runtime error when accessed
Full discussion (including context and workaround):
#jco > Unexpected error when using async JS types/functions with im
Related to #1313, but this issue is about missing initialization of
_isHostProvided.When mapping a JS class as an async WIT resource using the
--mapoption,_isHostProvidedis not initialized.In contrast, when using
--instantiation,_isHostProvidedis initialized correctly.Even if issue #1313 is fixed,
_isHostProvidedremains undefined for JS class.As a result, the following branch is never taken:
Actual behavior:
_isHostProvidedis not initialized,hostProvidedis always falthy (e.g.undefined)nullorundefined, leading to a runtime error when accessedFull discussion (including context and workaround):
#jco > Unexpected error when using async JS types/functions with im