-
Notifications
You must be signed in to change notification settings - Fork 15
feat: Implement strict validation for client while loading tools #205
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
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
e5763b9
to
be9ec4b
Compare
be9ec4b
to
2e36f66
Compare
2e36f66
to
ea1a66b
Compare
kurtisvg
approved these changes
May 8, 2025
anubhav756
added a commit
that referenced
this pull request
May 10, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 10, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
f56cc68
to
6ff0142
Compare
We will remove this once we actually implement the `strict` flag and centralize this functionality by moving this check to the tool's constructor in a future PR.
1bf4ab5
to
e7683f4
Compare
Merged
anubhav756
added a commit
that referenced
this pull request
May 12, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 14, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 14, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 14, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 14, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 14, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 14, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 15, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 15, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 16, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 16, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 16, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 16, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 16, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 16, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 16, 2025
…lity This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
anubhav756
added a commit
that referenced
this pull request
May 16, 2025
…lity (#236) * fix(toolbox-langchain)!: Base toolbox-langchain over toolbox-core * fix: add toolbox-core as package dependency * fix: Base sync client * fix: Fix running background asyncio in current loop issue * fix: Base toolbox sync & async tools to toolbox core counterparts * fix: Fix getting pydantic model from ToolboxSyncTool * fix: Fix issue causing async core tools for creating sync tools * fix: Fix reading name from correct param * fix: Fix issue of unknown parameter due to pydantic initialization * fix: Fix nit error + add comment * fix: Fix sync tool name assertion * chore: Temporarily remove unittests * chore: Remove unused strict flag + fix default values + fix docstring * fix: Update package to be from git repo * fix: Fix toolbox-core package local path * fix: Fix local package path * fix: Update git path * fix: Fix tests * fix: Fix using correct object for fetching loop * fix: Return invoke result * fix: Integration test errors * chore: Delint * fix: Fix integration test * fix: Fix integration tests * chore: Add unit tests previously deleted * chore: Delint * fix: Fix using correct protected member variables * chore: Delint * chore: Fix types * fix: Ensure bg loop/thread not null * fix: Check bg loop/thread value * fix: Revert warnings to prefer auth_tokens over auth_headers * chore: Update unittests * docs: Improve docstrings * chore: Add TODO note * chore: Improve TODO note * fix: Fix integration test * chore: Delint * chore: Rename internal member variable names to be more concise * chore: Delint * chore: Add toolbox actual package version in toml and local path in requirements.txt * fix: Fix editable toolbox-core package path in requirements.txt * fix: Fix lowest supported version until released * fix: Fix issue causing relative path in requirements.txt to cause issues * docs: Fix issue README * fix: Use correct core client interfaces in langchain client * fix: Use correct core tool interfaces in langchain tool * fix: Use correct interface from core tool * fix: Use correct interfaces of toolbox-core * chore: Update async client unit tests * chore: Fix client unit tests * chore: Delint * chore: Fix tools unit tests * chore: Restore add_auth_token(s) as deprecated for backward compatibility This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead. > [!NOTE] > The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request introduces a
strict
mode to theload_toolset
method and refines the validation behavior of theload_tool
method.Benefits
Changes
load_toolset(strict: bool = False)
The
load_toolset
method now includes an optionalstrict
flag:strict = False
(Default Behavior):ValueError
) if at least one authentication token getter (from theauth_token_getters
provided) or at least one bound parameter (from thebound_params
provided) is not utilized by any of the tools loaded within the toolset. This ensures that all globally provided configurations find a consumer within the set.strict = True
:load_toolset
call.load_tool()
strict
flag has been intentionally omitted from theload_tool
method.load_tool
is now standardized to be inherently strict: the single loaded tool must utilize all provided auth token getters and all provided bound parameters.load_tool
processes only one tool at a time. In this context, the nuanced behaviors ofstrict = True
versusstrict = False
(as defined forload_toolset
) do not apply; the expectation for a single tool is always full utilization of its provided configurations.Implementation
The validation logic leverages the
used_auth_keys
andused_bound_keys
values returned by the internal__parse_tool
helper function. This information indicates which specific auth token getters and bound parameters are actively used by each processed tool.Note
The
strict
flag available inload_toolset
is a runtime parameter that governs the validation behavior during the loading process. It is not persisted as part of the tool's loaded configuration or state.This is because at the level of an individual tool's direct configuration (e.g., if one were to add an auth token getter directly to a single tool instance), the "strictness" is inherent: that single tool would naturally be expected to use the configuration specifically provided to it. This aligns with the always-strict validation now enforced by the
load_tool
method.