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

  1. Ensure the JS interop bundle and the .NET runtime are the same version (update both NuGet and the JS package).
  2. If using a custom transport, verify it forwards the exact JSCallResultType enum value.
  3. Clear the browser cache / service-worker cache to drop a stale JS bundle.
  4. 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

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


AI-assisted analysis of dotnet/aspnetcore@294cab2f9b (2026-08-06). Data as JSON: /api/errors/8bef133e27e56f59. Report an issue: GitHub.