dotnet/aspnetcore · critical
Invalid JS call result type '${resultType}'.
Error message
Invalid JS call result type '${resultType}'. What it means
Thrown by createJSCallResult in its default branch. The switch over JSCallResultType covers Default, JSObjectReference, JSStreamReference, JSVoidResult; reaching default means the framework received a numeric resultType outside the enum's defined range. This is an internal contract violation: the resultType is chosen by the framework plumbing based on the .NET return-type hint, not by user code.
Source
Thrown at src/JSInterop/Microsoft.JSInterop.JS/src/src/Microsoft.JSInterop.ts:805
this.streamPromise = new Promise((resolve, reject) => {
this.resolve = resolve;
this.reject = reject;
});
}
}
function createJSCallResult(returnValue: any, resultType: JSCallResultType) {
switch (resultType) {
case JSCallResultType.Default:
return returnValue;
case JSCallResultType.JSObjectReference:
return createJSObjectReference(returnValue);
case JSCallResultType.JSStreamReference:
return createJSStreamReference(returnValue);
case JSCallResultType.JSVoidResult:
return null;
default:
throw new Error(`Invalid JS call result type '${resultType}'.`);
}
}
let nextByteArrayIndex = 0;
function stringifyArgs(callDispatcher: CallDispatcher, args: any[] | null) {
nextByteArrayIndex = 0;
currentCallDispatcher = callDispatcher;
const result = JSON.stringify(args, argReplacer);
currentCallDispatcher = undefined;
return result;
}
function getCaptureIdFromElement(element: Element): string | null {
for (let i = 0; i < element.attributes.length; i++) {
const attr = element.attributes[i];
if (attr.name.startsWith("_bl_")) {
return attr.name.substring(4);
}View on GitHub (pinned to 294cab2f9b)
Solutions
- Ensure the JS interop bundle and the .NET runtime are the same version (update both NuGet and the JS package).
- If using a custom transport, verify it forwards the exact JSCallResultType enum value.
- Clear the browser cache / service-worker cache to drop a stale JS bundle.
- Report as a framework bug if it reproduces with matched versions.
Example fix
// before // server runtime 8.0.2 + cached JS bundle 7.0.5 -> unknown resultType // after // bump JS interop package to match runtime, force cache-bust // <script src="_framework/blazor.web.js?v=8.0.2"></script>
Defensive patterns
Strategy: try-catch
Validate before calling
// verify version match before trusting results
const runtimeVer = await JS.InvokeAsync<string>('__getRuntimeVersion');
if (runtimeVer !== EXPECTED_JS_VER) throw new Error('JS/.NET version mismatch'); Type guard
null
Try / catch
try { await JS.InvokeAsync<object>('fn'); } catch (e) { if (/Invalid JS call result type/i.test(e.message)) { location.reload(true); } else throw e; } Prevention
- Keep the JS interop bundle and .NET runtime on the same version.
- Bust browser/service-worker caches of the JS bundle after upgrades.
- Treat this error as fatal and force a reload/reconnect.
When it happens
Trigger: A version skew between the .NET runtime and the JS interop bundle where new/renamed JSCallResultType values are sent; a corrupted/truncated payload flipping the resultType bits; a custom interop host emitting an unknown resultType. App code cannot normally pass an arbitrary value here.
Common situations: Mixing a newer server runtime with an older Microsoft.JSInterop.js bundle (or vice versa); a misbehaving custom transport; bit-flips in long-running stress.
Related errors
- There is no pending async call with ID ${asyncCallId}.
- Byte array index '${index}' does not exist.
- Invalid component type '${type}'.
- Unexpected renderer ID '${rendererId}' encountered while dis
- Cannot create a JSObjectReference from the value '${jsObject
AI-assisted analysis of dotnet/aspnetcore@294cab2f9b (2026-08-06).
Data as JSON: /api/errors/8bef133e27e56f59.
Report an issue: GitHub.