-
-
Notifications
You must be signed in to change notification settings - Fork 19
Moved the future in :on-tools-called and stored it in the db. #119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moved the future in :on-tools-called and stored it in the db. #119
Conversation
The future in the :on-tools-called callback used to be just before the check for @approved*. There is really no need to have a future when the call has been rejrected, only when the call has been allowed and ready to go. So, the future was moved to just before the call. To prepare for being able to cancel the call future, the future needs to be stored in the db. This is done by a new action `set-call-future` that is called on the :execution-start event. However, the since the future starts running as soon as it s created, we have to first delay the future and then force it only after the tool call state has been transitioned to :executing.
I would like to run a manual test before making this PR ready for review. |
This PR is a part of Issue #111 and is a prerequisite for what is to follow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes look good @bombaywalla I will test it, is there anything else you wanna do or is this ready to review?
I was just hoping to do a manual test, but it's ready to review otherwise. |
I've done some manual testing. |
Thank you, will review/test now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works!
The future in the
:on-tools-called
callback used to be just before the check for@approved*
. There is really no need to have a future when the call has been rejected, only when the call has been allowed and ready to go. So, the future was moved to just before the call.To prepare for being able to cancel the call future, the future needs to be stored in the db. This is done by a new action
set-call-future
that is called on the:execution-start
event. However, since the future starts running as soon as it s created, we have to first delay the future and then force it only after the tool call state has been transitioned to:executing
.There should be no change in external behavior.