No ToolCallback found for tool name:

[ljhlovw]

I am using Spring AI version 1.0.0.3.

main error is "No ToolCallback found for tool name: terminate
java.lang.IllegalArgumentException: Functional bean with name generateSql does not exist in the context.
at org.springframework.ai.tool.resolution.TypeResolverHelper.getBeanDefinition(TypeResolverHelper.java:150)
at org.springframework.ai.tool.resolution.TypeResolverHelper.resolveBeanType(TypeResolverHelper.java:128)
at org.springframework.ai.tool.resolution.SpringBeanToolCallbackResolver.resolve(SpringBeanToolCallbackResolver.java:92)
java.lang.IllegalStateException: No ToolCallback found for tool name: terminate "

I have added the @tool annotation and injected the class into the Spring container, but I still get the error: "No ToolCallback found for tool name: terminate". I noticed that these tools are registered in the ReActChatClient object, but when the large language model tries to use the tools, it throws an error.

I can't figure out where the problem is. I'm asking for help from all the experts to point me in the right direction.

[ljhlovw]

I know the root cause now:
When I initialized the chat-model I set internalToolExecutionEnabled = false in its original ChatOptions.
That flag tells Spring-AI "the model itself will NOT execute any tools; the caller will do it".
But later, inside my own ToolManager, I created a brand-new ChatOptions instance and passed it to the model.
Because that new options object was not the one the ChatClient started with, it contained zero ToolCallbacks.
When the framework tried to convert the model’s current options to ToolCallingOptions (so it could retrieve the callbacks), it found nothing and the tool calls failed.
Why must we keep using the original ChatOptions?
During tool execution Spring-AI has to turn the model’s options into a ToolCallingOptions object so it can extract the ToolCallback[].
That array is injected only once—inside the .call() stage of
chatClient.prompt().user().call().
At that moment the callbacks are copied into the original options object that the ChatClient was built with.
If, later, you swap in any other options instance, the callbacks are lost and the manual tool-execution path breaks.