fix(tools): raise ToolUsageError instead of bare raise in _original_tool_calling#6448
fix(tools): raise ToolUsageError instead of bare raise in _original_tool_calling#6448C0d3N1nja97342 wants to merge 2 commits into
Conversation
…ool_calling ToolUsage._original_tool_calling executed a bare `raise` outside any except block when _validate_tool_input returned a non-dict and raise_error=True. With no active exception this raised `RuntimeError: No active exception to re-raise` instead of a meaningful error. Raise a constructed ToolUsageError, consistent with the raise_error=False return path. The sole caller (_tool_calling) still catches it via `except Exception` and falls back to function-calling, so behavior is backward compatible.
Add regression tests for _original_tool_calling: happy path returns ToolCalling; non-dict with raise_error=True raises ToolUsageError (not RuntimeError); non-dict with raise_error=False returns ToolUsageError. Mirrors the patch.object style of test_tool_validate_input_error_event.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe PR fixes a bare ChangesBare Raise Fix and Regression Tests
Related Issues: Suggested Labels: bug, tests Suggested Reviewers: None specifically identified Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Problem
ToolUsage._original_tool_calling(lib/crewai/src/crewai/tools/tool_usage.py) executed a bareraiseoutside anyexceptblock when_validate_tool_inputreturned a non-dict andraise_error=True. Because no exception was active on that path (the precedingtry/excepthad completed normally), Python raisedRuntimeError: No active exception to re-raiseinstead of a meaningful error. This produced a confusing error message and caused the caller_tool_callingto log/retry against aRuntimeErrorrather than a descriptiveToolUsageError.Reported in #6430.
Solution
Construct a
ToolUsageErroronce andraiseit whenraise_error=True(or return it whenraise_error=False), mirroring the existingraise_error=Falsereturn path. The sole caller_tool_callingstill catches it viaexcept Exceptionand falls back to_function_calling/ retry exactly as before, so behavior is backward compatible — the only difference is that the exception now carries a meaningful message instead ofRuntimeError.No signature, return-type annotation, or public API change. Minimal and scoped to the bug.
Changes
lib/crewai/src/crewai/tools/tool_usage.py— in_original_tool_calling, replaced the bareraisein the non-dict branch withraise tool_arguments_error(a constructedToolUsageError); theraise_error=Falsepath returns the same object.lib/crewai/tests/tools/test_tool_usage.py— addedToolUsageErrorimport, a smallToolUsagebuilder helper, and 3 tests covering:ToolCalling)raise_error=True→ raisesToolUsageError(regression: wasRuntimeError)raise_error=False→ returnsToolUsageError(compatibility)Testing
uv run pytest lib/crewai/tests/tools/test_tool_usage.py -k original_tool_calling→ 3 passed.ruff checkandruff format --checkare clean on the changed files.test_tool_usage.pyfail locally on a cleanmaincheckout (confirmed viagit stash+ re-run) — they are environment/flaky (threading + event bus on Windows) and unrelated to this change.Notes for Reviewer
.github/CONTRIBUTING.md, thellm-generatedlabel is required — I've attempted to apply it; if the tooling does not permit external contributors to label PRs, please add it.if not isinstance(arguments, dict)branch rather than removing it. Since_validate_tool_inputcurrently guarantees dict-or-raise, the branch is effectively defensive/dead, but I chose the minimal fix (correct theraise) over removing the branch to keep the change scoped to the bug. Happy to remove the branch instead if preferred.