Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

[spring-ai] Wrapping ChatModels without getOptions() override fail with ClassCastException when ADK tools are attached

Aberta
  • Algo errado?
#1,731 0 comentários 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 1 dia

@hirematha já está trabalhando nisso.

Desde 30/10/2026.

Avaliação

Esta issue ainda não foi avaliada.

Descrição

Describe the Bug

When the configured ChatModel is a delegating/wrapping implementation that does not override getOptions() (the interface default returns an empty DefaultChatOptions), any ADK request with tools fails with a bare ClassCastException deep inside the provider model.

Chain:

  1. SpringAI.resolveDefaultOptions() returns the model's getOptions() — for wrappers, the interface default: an empty DefaultChatOptions, not null, so the existing null handling never engages;
  2. MessageConverter.buildChatOptions(...) sees defaults that are not ToolCallingChatOptions and falls into the hasTools branch, building provider-neutral ToolCallingChatOptions;
  3. Provider models that cast Prompt.getOptions() to their own type — e.g. OpenAiChatModel.createRequest(...) casting to OpenAiChatOptions — throw ClassCastException: DefaultToolCallingChatOptions cannot be cast to OpenAiChatOptions.

The failure surfaces several frames away from the cause and gives no hint that the wrapper's getOptions() is the origin. We hit this in production with a failover wrapper (2026-09-28): the non-streaming fallback path died on its first call.

Note the related hardening in resolveDefaultOptions() (avoiding the same cast by using the model's own options) covers the "options available" half; this report is the "defaults are the empty interface default" half.

To Reproduce
// Any delegating wrapper that forgets to override getOptions()
class ForgettingWrapper implements ChatModel, StreamingChatModel {
  private final ChatModel delegate;
  // call()/stream() delegate; getOptions() intentionally NOT overridden
}

SpringAI springAI = new SpringAI(new ForgettingWrapper(openAiChatModel));
springAI.generateContent(
    LlmRequest.builder()
        .contents(List.of(userContent("hello")))
        .tools(Map.of("ping", pingTool))   // any ADK tool
        .build(),
    false);
// -> RuntimeException wrapping ClassCastException:
//    DefaultToolCallingChatOptions cannot be cast to org.springframework.ai.openai.OpenAiChatOptions

(Verified with a probe test on current main: the wrapper's getOptions() returns DefaultChatOptions@..., instanceof ToolCallingChatOptions is false, and the cast fails exactly as above.)

Expected behavior

At minimum, an actionable warning/error at the bridge level naming the actual cause ("the wrapping model's getOptions() returns non-provider options; delegate it to the underlying model's options"), instead of a bare ClassCastException from inside the provider. Fail-fast would also be reasonable, except that dummy/test models legitimately use the same default — so we prototyped a WARN in MessageConverter.buildChatOptions (branch: https://github.com/google/adk-java/compare/main...caps-xia:adk-java:fix/wrapper-chatmodel-options-cce, 307 tests green) and are happy to open a PR if the direction sounds right.

Environment
  • google/adk-java main (post the resolveDefaultOptions hardening)
  • Spring AI 2.0.1, spring-ai-openai
Additional context

Wrapping/decorating ChatModels (failover, retry, caching, audit) are a common Spring AI pattern; any of them without an explicit getOptions() override hits this the moment ADK tools are attached. A one-line doc note in the SpringAI README ("wrappers must delegate getOptions()") would also help.

Linguagem predominante
Java
Estrelas
1.8k
Forks
442
Merge médio
3d 13h
PRs com merge (30d)
95

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de google/adk-java

Todas as issues de google/adk-java

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.