dependency resolution on a non-JS thread fails with 0x80131509 instead of falling back
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 70/100
Hướng nghiên cứu
Start with ManagedHost.OnResolvingAssembly in src/NodeApi.DotNetHost/ManagedHost.cs, especially the FileNotFoundException handler and adjacent-directory fallback. Read how the resolving event is emitted and how JSValueScope.CurrentOrNull indicates whether a JS scope is active. Reproduce the off-thread case using the linked minimal repo; done when assembly resolution reaches the adjacent-directory fallback without throwing on a thread with no JS scope.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Environment
- node-api-dotnet /
Microsoft.JavaScript.NodeApi(.*): 0.9.27 - Node.js: v24.19.0 (Windows x64)
- .NET runtime loaded by the host: 8.0.29
Summary
When a dependency assembly is first resolved on a thread that has no JS value scope (a .NET thread-pool
thread in the example below), ManagedHost.OnResolvingAssembly throws JSInvalidThreadAccessException while
trying to emit the resolving event.
The runtime exposes that as a FileLoadException:
System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. An operation is not legal in the current state. (0x80131509)
---> Microsoft.JavaScript.NodeApi.JSInvalidThreadAccessException: There is no active JS value scope.
Current thread: #4 ".NET TP Worker". Consider using the synchronization context to switch to the JS thread.
Note this is 0x80131509 (COR_E_INVALIDOPERATION), not 0x80070002 (file not found): in the repro the assembly is next to the module, so the message points away from the cause.
It also throws before the loader's next step, which looks for the assembly in the same directory as any already-loaded assemblies: see https://github.com/microsoft/node-api-dotnet/blob/main/src/NodeApi.DotNetHost/ManagedHost.cs#L280-L316
try
{
assembly = LoadAssembly(assemblyName, allowNativeLibrary: false);
}
catch (FileNotFoundException)
{
// not found in the system directories.
// Emit a resolving event to allow listeners to load the assembly.
Emit( ResolvingEventName, assemblyName, assemblyVersion!,
new JSFunction(ResolveAssembly) //////// may throw here: building the JSValue/JSFunction arguments requires a JS scope
);
_loadedAssembliesByName.TryGetValue(assemblyName, out assembly);
}
/////////// not reached when the Emit above throws
if (assembly == null)
{
// The dependency assembly was not resolved by an event-handler.
// Look for it in the same directory as any already-loaded assemblies.
// ...
}
Minimal reproduction
see the minimal repo that reproduces
Trace evidence (NODE_API_TRACE_HOST=1)
resolve assembly on .NET Task Pool:
> ManagedHost.OnResolvingAssembly(Newtonsoft.Json, 13.0.0.0)
> ManagedHost.LoadAssembly(Newtonsoft.Json) <-- (1) framework dirs
[repro] ... FileLoadException 0x80131509 / JSInvalidThreadAccessException ".NET TP Worker"
<-- no `ManagedHost.LoadAssembly(<path>)` line, no `not found at ...` line: (3) never ran
resolve assembly on JS Scope:
> ManagedHost.OnResolvingAssembly(Newtonsoft.Json, 13.0.0.0)
> ManagedHost.LoadAssembly(Newtonsoft.Json)
> ManagedHost.LoadAssembly(<module dir>\Newtonsoft.Json.dll) <-- (3) adjacent-directory fallback
< ManagedHost.OnResolvingAssembly(Newtonsoft.Json) => <module dir>\Newtonsoft.Json.dll
Impact
- the adjacent-directory fallback never runs when resolution happens off the JS thread, so a dependency that would have resolved fails
- The error message is misleading
Suggested
Skip the notification when there is no JS scope. Since there's no JSValueScope, there's no need to report to JS
catch (FileNotFoundException)
{
// guard: use the existing internal api
if (JSValueScope.CurrentOrNull is not null)
{
Emit(ResolvingEventName, assemblyName, assemblyVersion!, new JSFunction(ResolveAssembly));
_loadedAssembliesByName.TryGetValue(assemblyName, out assembly);
}
}
With this, it will fallback to the next step.
Further Requests
Orthogonal to this report: the host's load context is private and its resolution policy is fixed, so a consumer
cannot use his own AssemblyLoadContext. It's better to allow developer to custom the ALC
- Ngôn ngữ chính
- C#
- Star
- 787
- Fork
- 80
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của microsoft/node-api-dotnet
-
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 88/100
microsoft/node-api-dotnet#484 ·
-
Embedding args occasionally get trailing garbage on .NET (missing null terminator on a pooled buffer)Có thể đã có người làm @tolmachev-pravo đã nhận 92 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
microsoft/node-api-dotnet#481 ·
-
JSError.ThrowError(Exception) aborts the process when a Worker terminates during a .NET callCó thể đã có người làm @GalaxiasKyklos đã nhận hôm nay. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 18/100
microsoft/node-api-dotnet#505 ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 82/100
microsoft/node-api-dotnet#502 ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
microsoft/node-api-dotnet#486 · 1 bình luận ·
Tất cả issue của microsoft/node-api-dotnet
Issue tương tự
-
documentation
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 62/100
-
bug misleading tooling trivial
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Docs example projects pinned to a literal library version instead of 3.*Có thể đã có người làm @DaveSkender đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
facioquo/stock-indicators-dotnet#2372 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Docs] officecli-docx SKILL.md still describes `\n` as a soft line break after #262Có thể đã có người làm @giprime đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Facepunch/sbox-public#12097 ·
Maintainer thường phản hồi trong vòng 2 ngày