This is a continuation of #218, which add a local quickstart for running
Toolbox with Python and LangGraph.
---------
Co-authored-by: Twisha Bansal <twishabansal@google.com>
Co-authored-by: Anubhav Dhawan <anubhav756@gmail.com>
Currently, we are throwing 401 error immediately after auth token
verification failure. This is not expected in the following situations:
1. Non-auth tool invocation with auth token that is invalid.
2. Auth tool invocation with all the required auth token, but the header
contains extra non-required token that is invalid
These requests should pass the authorization check but fail under the
current implementation.
Change made in this PR:
1. Do not throw error immediately after auth token verification failure.
Instead only log it and continue to the next header iteration.
2. In the parseParams() method, if an auth parameter is missing, we
should error with the message telling the user that either the auth
header is missing or is invalid.
1. `sql/database` provides a `Scan()`interface to scan query results
into typed variables. Therefore we have to create a slice of typed
variables (types retrieved from rows.ColumnTypes()) to pass them into
`Scan()`. Using []byte works but makes the printing result different
from other tools (e.g [1] instead of %!s(int32=1)]
2. MS SQL supports both named (e.g @name) and positional args (e.g @p2),
so we have to check if the name is contained in the original statement
before passing them into `db.Query()` as either named arg or as values.
Add CloudSQL for MySQL source and tool.
CloudSQLMySQL source is initialize with the following config:
```
sources:
my-cloudsqlmysql-source:
kind: cloud-sql-mysql
project: my-project-name
region: my-region
instance: my-instance-name
user: my_user
password: my_pass
database: my_db
# ipType: public # The default dialect is public.
```
MySQL tool is initialize with the following config.
```
tools:
test_tool:
kind: mysql
source: my-cloudsqlmysql-source
description: >
Testing tool.
statement: "SELECT 1;"
```
The newly implemented `ToolboxTool` class manages tool state and
supports this new feature of binding parameters along wiith the existing
OAuth.
> [!NOTE]
> These changes are done in the LlamaIndex SDK as well in #203, along
with documentation updates in #193.
# `ToolboxTool` Class
The newly implemented `ToolboxTool` class manages tool state and
supports features like bound params and OAuth.
We have also added the logic as well as state related to bound params to
`ToolboxTool` in #192.
`ToolboxTool` follows a functional approach, meaning it ensures that the
internal tool state remains unchanged and a new copy of the tool is
updated with the new values of auth tokens (or bound params from #192).
## `ToolboxTool` Class Diagram
To better explain, here's a visual diagram of the ToolboxTool class.
The boxes have member function names, and the "red" box means a function
is mutating the internal state, while "green" means it does not change
the internal state (like a C++ `const` function or JS immutable
function). The red box also shows the member variable they mutated.
## Constructor
From the diagram above, it is evident that all the state changes, or
rather setting of the state, is done in the class constructor.
For further reference, here's a visual explanation of the functionality
of the constructor showing which params we add as auth tokens, which
params we add to the underlying schema, and for what the error/warnings
are thrown.
> [!NOTE]
> Documentation updates are done by #193 and the corresponding changes
to the LlamaIndex SDK are done by #203.
- configure neo4j source with url, username, password, database
- configure neo4j tools with cypher statement and paramters
- tests based on the postgres tests
- neo4j.yaml for integration tests
---------
Co-authored-by: duwenxin <duwenxin@google.com>
1. Add generic integration test helpers for authenticated parameters and
auth-required tool invocations.
2. Call generic test helpers as Cloud SQL integration tests.
Add debug logs to Toolbox.
For example when a http fail, it will just show Error at the http level,
but not log with actual error message. err message are returned to the
api as following `{"status":"Internal Server Error","error":"error while
invoking tool: unable to execute client: spanner: code =
\"InvalidArgument\", desc = \"invalid session pool\""}`.
After adding this, if user/dev run toolbox with `--log-level=debug`, it
will output the following (debug log in addition to the error for http
request):
```
2025-01-08T14:16:25.040824-08:00 DEBUG "error while invoking tool: unable to execute client: spanner: code = \"InvalidArgument\", desc = \"invalid session pool\""
2025-01-08T14:16:25.040968-08:00 ERROR Response: 500 Server Error service: "httplog" httpRequest: {url: "http://127.0.0.1:5000/api/tool/test_tool_two/invoke" method: "POST" path: "/api/tool/test_tool_two/invoke" remoteIP: "127.0.0.1:51708" proto: "HTTP/1.1" requestID: "yuanteoh-macbookpro.roam.internal/N7LNMcLIUH-000001" scheme: "http" header: {user-agent: "curl/8.7.1" accept: "*/*" content-type: "application/json" content-length: "2"}} httpResponse: {status: 500 bytes: 167 elapsed: 0.301917}
```
This PR contains toolbox Set up and e2e tests for the following
functionality:
- Load tools
- Load toolsets
- Running tools
- Auth for tools
- Auth for tool parameters
---------
Co-authored-by: Anubhav Dhawan <anubhav756@gmail.com>
Corrects an issue caused by Go defaulting to parsing JSON Numbers as
float64s. This caused some numbers to be incorrectly parsed as floats
when they were integers. This defaults to parsing using json.Number,
which allows us to parse between Int/Float more accurately.
Adds logic to make the server shutdown gracefully, including better
respecting cancelled contexts and providing up to 10 seconds to finish
current connections.
Client code should not be concerned with how authentication tokens are
handled internally. This commit refactors method and parameter names to
use the more abstract term "token" instead of "header," improving the
developer experience and hiding implementation details.
End to end integration test for postgres.
Include checks for one tool's get (manifest) and post (invoke) endpoint.
Integration tests are excluded from regular unit tests.
