continuedev/continue · warning

Unsupported tool call type in Bedrock: ${tool.type}

Error message

Unsupported tool call type in Bedrock: ${tool.type}

What it means

During message conversion for Bedrock, tool calls on assistant messages are serialized into text blocks when their type is recognized (e.g. "function"). A tool entry with any other type falls into the else branch, logs this warning, and is dropped from the converted message — the tool call context is lost for that request.

Source

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

                currentBlocks.push({
                  toolUse: {
                    toolUseId: toolCall.id,
                    name: toolCall.function.name,
                    input: safeParseArgs(
                      toolCall.function.arguments,
                      `Call: ${toolCall.function.name} ${toolCall.id}`,
                    ),
                  },
                });
                hasAddedToolCallIds.add(toolCall.id);
              } else {
                const toolCallText = `Assistant tool call:\nTool name: ${toolCall.function.name}\nTool Call ID: ${toolCall.id}\nArguments: ${toolCall.function?.arguments ?? "{}"}`;
                currentBlocks.push({
                  text: toolCallText,
                });
              }
            } else {
              console.warn(
                `Unsupported tool call type in Bedrock: ${toolCall.type}`,
              );
            }
          }
        }
      }
    }

    if (currentBlocks.length > 0) {
      pushCurrentMessage();
    }

    // If caching is enabled, add cache points
    // if (this.config.cacheBehavior?.cacheConversation) {
    //   this._addCachingToLastTwoUserMessages(converted);
    // }

    return converted;

View on GitHub (pinned to 5522c6f44c)

Solutions

  1. Normalize tool call entries to type: "function" with function: { name, arguments, } and a string id before sending
  2. Validate recorded/replayed histories: drop or map unknown tool types upstream
  3. If you control the upstream model output, ensure it emits standard OpenAI function tool calls

Example fix

// before
toolCalls: [{ id: "1", type: "custom_tool", custom: {...} }]

// after
toolCalls: [{ id: "1", type: "function", function: { name: "myTool", arguments: "{}" } }]
Defensive patterns

Strategy: type-guard

Validate before calling

if (toolCalls.some((t) => t.type !== "function")) {
  throw new Error("All tool calls must be type 'function' for Bedrock");
}

Type guard

const isFunctionToolCall = (t: unknown): t is { id: string; type: "function"; function: { name: string; arguments: string } } =>
  !!t && (t as any).type === "function" && typeof (t as any).function?.name === "string";

Prevention

When it happens

Trigger: Passing an assistant message with tool calls whose type is not "function" — e.g. custom tool types, future OpenAI variants, or malformed objects where type is undefined/misspelled.

Common situations: Hand-building message histories, replaying recorded OpenAI traffic with newer tool types, or bugs that produce tool objects without a type field.

Related errors


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