What causes "Invalid component type '${type}'." in dotnet/aspnetcore?

Align the .NET server package version and the blazor.*.js bundle version (check blazor.boot.json hash references).

Invalid component type '${type}'.

Error message

Invalid component type '${type}'.

What it means

Thrown by parseCommentPayload (ComponentDescriptorDiscovery.ts:173) when a Blazor component marker's JSON has a 'type' field that is not one of 'server', 'webassembly', or 'auto'. The type discriminator tells discovery which renderer should own the component; an unknown value means the marker was produced by a version of the framework the running blazor.*.js does not understand.

Source

Thrown at src/Components/Web.JS/src/Services/ComponentDescriptorDiscovery.ts:173

          case 'server':
            return createServerComponentComment(componentComment, candidateStart as Comment, candidateEnd);
          case 'auto':
            return createAutoComponentComment(componentComment, candidateStart as Comment, candidateEnd);
        }
      } catch (error) {
        throw new Error(`Found malformed component comment at ${candidateStart.textContent}`);
      }
    } else {
      return;
    }
  }
}

function parseCommentPayload(json: string): ServerComponentMarker | WebAssemblyComponentMarker | AutoComponentMarker {
  const payload = JSON.parse(json);
  const { type } = payload;
  if (type !== 'server' && type !== 'webassembly' && type !== 'auto') {
    throw new Error(`Invalid component type '${type}'.`);
  }

  return payload;
}

function assertNotDirectlyOnDocument(marker: Node) {
  if (marker.parentNode instanceof Document) {
    throw new Error('Root components cannot be marked as interactive. The <html> element must be rendered statically so that scripts are not evaluated multiple times.');
  }
}

function getComponentEndComment(payload: ComponentMarker, start: Comment, iterator: ComponentCommentIterator): Comment | undefined {
  const { prerenderId } = payload;
  if (!prerenderId) {
    return undefined;
  }

  while (iterator.next() && iterator.currentElement) {

View on GitHub (pinned to 294cab2f9b)

Solutions

Align the .NET server package version and the blazor.*.js bundle version (check blazor.boot.json hash references).
Bust the CDN/browser cache of blazor.web.js and prerendered HTML after upgrades.
If you customize component marker rendering, ensure type stays within the allowed set.
Reproduce locally with matched versions to confirm the marker is well-formed.

Example fix

// before: cached blazor.web.js v8 reading a v9 'type':'web' marker

// after: clear cached assets and serve matching versions
// <script src="_framework/blazor.web.js"></script> matches the installed package

Defensive patterns

Strategy: validation

Validate before calling

const ALLOWED_TYPES = new Set(['server','webassembly','auto']);
function isValidMarkerType(payload: unknown): payload is { type: string } {
  return typeof payload === 'object' && payload !== null
    && ALLOWED_TYPES.has((payload as any).type);
}

Type guard

function isKnownComponentType(type: string): type is 'server'|'webassembly'|'auto' {
  return type === 'server' || type === 'webassembly' || type === 'auto';
}

Prevention

Pin server and blazor.*.js to the same release.
Cache-bust blazor.web.js and prerendered HTML after upgrades.
Do not hand-build component markers.

When it happens

Trigger: A marker comment whose JSON payload has type:<anything-other-than-server|webassembly|auto>; typically a newer/older marker schema served against a mismatched blazor.*.js bundle; hand-edited or cached HTML with a stale marker.

Common situations: Version mismatch between the .NET runtime generating markers and the JS bundle interpreting them (e.g. upgraded NuGet package but stale cached blazor.web.js); serving cached prerendered HTML from a CDN after a framework upgrade; A/B testing or edge worker rewriting JSON inside comments.

Related errors

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