continuedev/continue · error · Error

Unsupported part type: input_audio

Error message

Unsupported part type: input_audio

What it means

When converting OpenAI-format chat messages to Bedrock Converse format, _oaiPartToBedrockPart maps each content part type; audio input parts ('input_audio') have no Bedrock equivalent in this adapter, so it throws rather than silently dropping the audio. The error fires per-part during message conversion, before any network call.

Source

Thrown at packages/openai-adapters/src/apis/Bedrock.ts:135

    });
  }

  private _oaiPartToBedrockPart(
    part:
      | OpenAI.Chat.Completions.ChatCompletionContentPart
      | OpenAI.Chat.Completions.ChatCompletionContentPartRefusal,
  ): ContentBlock {
    switch (part.type) {
      case "refusal":
        return {
          text: part.refusal,
        };
      case "text":
        return {
          text: part.text,
        };
      case "input_audio":
        throw new Error("Unsupported part type: input_audio");
      case "image_url":
      default:
        const parsed = parseDataUrl(
          (part as ChatCompletionContentPartImage).image_url.url,
        );
        if (!parsed) {
          console.warn("Bedrock: failed to process image part - invalid URL");
          return { text: "[Failed to process image]" };
        }
        const { mimeType, base64Data } = parsed;
        const format = mimeType.split("/")[1]?.split(";")[0] || "jpeg";
        if (
          format === ImageFormat.JPEG ||
          format === ImageFormat.PNG ||
          format === ImageFormat.WEBP ||
          format === ImageFormat.GIF
        ) {
          return {

View on GitHub (pinned to 5522c6f44c)

Solutions

  1. Strip or reject 'input_audio' parts before sending to Bedrock; convert audio to text via a transcription API (e.g. Whisper) and send the transcript as a text part
  2. Route audio-capable requests to a provider that supports input_audio (e.g. OpenAI gpt-4o-audio-preview)
  3. Validate message parts against a whitelist per provider before dispatch

Example fix

// before
messages: [{ role: 'user', content: [
  { type: 'text', text: 'transcribe this' },
  { type: 'input_audio', input_audio: { data: b64, format: 'wav' } },
]}]

// after (transcribe first, send text)
const text = await transcribe(b64);
messages: [{ role: 'user', content: [{ type: 'text', text: `transcribe this: ${text}` }] }]
Defensive patterns

Strategy: type-guard

Validate before calling

const BEDROCK_PART_TYPES = new Set(['text', 'image_url']);
const bad = msgs.flatMap(m => m.content ?? []).filter(p => !BEDROCK_PART_TYPES.has(p.type));
if (bad.length) throw new Error(`Unsupported part(s) for Bedrock: ${bad.map(p => p.type).join(', ')}`);

Type guard

const isBedrockSupportedPart = (
  part: ChatCompletionContentPart,
): part is ChatCompletionContentPartText | ChatCompletionContentPartImage =>
  part.type === 'text' || part.type === 'image_url';

Try / catch

try { return await bedrock.chatCompletion(body, signal); }
catch (e) {
  if (e instanceof Error && e.message === 'Unsupported part type: input_audio') {
    return transcribeAndRetry(body); // or route to an audio-capable provider
  }
  throw e;
}

Prevention

When it happens

Trigger: Sending a chatCompletion/stream request whose message content includes a part with type: 'input_audio' (inline base64 audio or recorded audio chunks) to the Bedrock provider.

Common situations: Building multimodal apps against OpenAI and then pointing the same code at Bedrock, which only supports text and image_url parts here; voice-input features that attach audio parts to messages; model-agnostic frontends that pass through whatever the client sends.

Related errors


AI-assisted analysis of continuedev/continue@5522c6f44c (2026-08-27). Data as JSON: /api/errors/1ded22c56a852fff. Report an issue: GitHub.