fix: Handling default implementation of ToolCallback#call(String,ToolContext) #3784
Conversation
There was a problem hiding this comment.
Thanks for this changes @ilayaperumalg. I've left a comment. The toolContext can never be null, which means the if check is entirely obsolete. Additionally, this only solves #3389 partially.
As a user it is still cumbersome to implement a ToolCallback which needs to use the ToolContext. I need to override the call(String) method and the call(String, ToolContext) method. Is there a reason why you are against providing a new interface ToolContextAwareToolCallback that would look like:
public interface ToolContextAwareToolCallback extends ToolCallback {
@Override
default String call(String toolInput) {
throw new UnsupportedOperationException("This method is not supported. Use call(String toolInput, ToolContext toolContext) instead.");
}
@Override
String call(String toolInput, @NonNull ToolContext toolContext);
}This interface is using the same pattern as other Spring ecosystem implementations.
| String toolResult; | ||
| try { | ||
| toolResult = toolCallback.call(toolInputArguments, toolContext); | ||
| if (toolContext != null) { |
There was a problem hiding this comment.
This can never be null. The toolContext cromes from buildToolContext, which never returns null.
There was a problem hiding this comment.
You are right. This can never be null and I will remove this unnecessary check.
We want to have a solution that can work for 1.0.x as well. Obviously, the new interface can only exist in 1.1.x. The simplest option is to ignore the ToolContext in the default implementation of call(String,ToolContext). |
Yes indeed the the new interface is not for 1.0.x. The fix (to ignore the If I understood it correctly, you would be open to the new interface in a separate PR for 1.1.x, right? This is in tangent to this PR and fixing the original problem I was facing. |
Introducing a new interface in 1.1.x would be fine. But, we are still discussing the need for one more ToolCallback interface and also the default implementation handles this in the PR now. |
…Context) Context: Currently, the default implementation of ToolCallback#call(String,ToolContext) throws exception when an non-empty ToolContext is passed. This gives bad user experience when the application has multiple tool callbacks with one of them doesn't use toolcontext but the chat client passes non-empty toolcontext. For more information #spring-projects#3389 - This fix removes the explicit exception when the toolcontext is non empty for the default implementation of call(String, ToolContext) - Instead, log info message that tool context will be ignored Resolves spring-projects#3389 Signed-off-by: Ilayaperumal Gopinathan <[email protected]>
ilayaperumalg
force-pushed
the
toolcallback-context-logging
branch
from
2522740 to
768997d
Compare
|
merged in 3e17e16 backported to 1.0.x |
4 participants
Context: Currently, the default implementation of ToolCallback#call(String,ToolContext) throws exception when an non-empty ToolContext is passed. This gives bad user experience when the application has multiple tool callbacks with one of them doesn't use toolcontext but the chat client passes non-empty toolcontext. For more information ##3389
This fix removes the explicit exception when the toolcontext is non empty for the default implementation of call(String, ToolContext)
Also, add explicit null check at the DefaultToolCallingManager when invoking ToolCallback's methods
Resolves #3389