vercel/ai · error

`Expected parsed tool-call stream part, got '${input.part.ty

Error message

`Expected parsed tool-call stream part, got '${input.part.type}'.`

What it means

Internal invariant check in `asToolCallTextStreamPart`: the function was handed a stream part whose `type` is not 'tool-call' when a parsed tool-call part was required. This is an SDK-internal type-narrowing assertion, so hitting it means an internal code path or a badly patched/extended stream pipeline passed the wrong part type.

Source

Thrown at packages/harness/src/agent/internal/run-prompt.ts:1159

  // rejection.
  done.catch(() => {});

  return { result, done };
}

type HostToolOutcome =
  | { ok: true; output: unknown }
  | { ok: false; error: unknown };

type HostToolExecution =
  | { executed: false }
  | { executed: true; outcome: HostToolOutcome };

function asToolCallTextStreamPart<TOOLS extends ToolSet>(input: {
  part: TextStreamPart<TOOLS>;
}): ToolCallTextStreamPart {
  if (input.part.type !== 'tool-call') {
    throw new Error(
      `Expected parsed tool-call stream part, got '${input.part.type}'.`,
    );
  }
  return input.part as ToolCallTextStreamPart;
}

type ToolCallTextStreamPart = {
  readonly type: 'tool-call';
  readonly toolCallId: string;
  readonly toolName: string;
  readonly input: unknown;
  readonly providerExecuted?: boolean;
  readonly providerMetadata?: unknown;
  readonly dynamic?: boolean;
  readonly invalid?: boolean;
  readonly error?: unknown;
  readonly title?: string;
};

View on GitHub (pinned to 69428b1f8b)

Solutions

  1. Pin all @ai-sdk/* packages to matching versions so stream part types are consistent.
  2. Remove or fix custom stream middleware/transformations that alter part types before this helper runs.
  3. If it reproduces on unmodified SDK code, file a bug with the harness and stream trace.

Example fix

// before
asToolCallTextStreamPart({ type: 'tool-result', ... }); // wrong part

// after
if (part.type === 'tool-call') {
  asToolCallTextStreamPart(part);
}
Defensive patterns

Strategy: type-guard

Type guard

function isToolCallPart<TOOLS extends ToolSet>(part: TextStreamPart<TOOLS>): part is Extract<TextStreamPart<TOOLS>, { type: 'tool-call' }> {
  return part.type === 'tool-call';
}

Try / catch

try {
  asToolCallTextStreamPart(part);
} catch (e) {
  if (e instanceof Error && e.message.startsWith('Expected parsed tool-call stream part')) {
    // inspect upstream stream transformation for part-type corruption
  }
  throw e;
}

Prevention

When it happens

Trigger: Any code path calling `asToolCallTextStreamPart` with a TextStreamPart whose `type` is something other than 'tool-call' (e.g. 'text', 'tool-result', 'error').

Common situations: Bugs in the SDK's own stream transformation pipeline; custom middleware or monkey-patches that reorder/relabel stream parts; version-mismatched @ai-sdk packages producing unexpected part types.

Related errors


AI-assisted analysis of vercel/ai@69428b1f8b (2026-08-30). Data as JSON: /api/errors/666fc0c9b8d21311. Report an issue: GitHub.