Describe the bug
On the current main (commit e54f8ca995dc80cc3e058171500948a24129b302), constructing GetObjectPositionsTool from rai.tools.ros2.manipulation.custom (also re-exported from rai.tools.ros2) raises:
pydantic.errors.PydanticUserError: `GetObjectPositionsTool` is not fully defined; you should define `GetGrabbingPointTool`, then call `GetObjectPositionsTool.model_rebuild()`.
The tool subclasses a Pydantic model and declares the field get_grabbing_point_tool: "GetGrabbingPointTool", but GetGrabbingPointTool is imported only inside an if TYPE_CHECKING: block, so the forward reference is never resolvable at runtime and no model_rebuild() call exists anywhere in the package. The failure happens even when the perception package is installed.
Relevant code on the default branch:
- Type imported only for type checking:
|
if TYPE_CHECKING: |
|
from rai_perception.tools import GetGrabbingPointTool |
- Field annotated with the forward reference:
|
get_grabbing_point_tool: "GetGrabbingPointTool" |
To Reproduce
- Install
rai with perception support so rai_perception is importable.
from rai.tools.ros2 import GetObjectPositionsTool, GetGrabbingPointTool
- Construct the tool normally, for example
GetObjectPositionsTool(connector=connector, get_grabbing_point_tool=GetGrabbingPointTool(connector=connector)).
- Observe the
PydanticUserError above. Generating the tool schema with GetObjectPositionsTool.model_json_schema() (which LangChain does when binding the tool to an LLM) fails the same way.
The repository's own callers construct the tool this way and hit the same error: examples/rosbot-xl-demo.py, examples/manipulation_common.py, and src/rai_bench/rai_bench/manipulation_o3de/benchmark.py.
Expected behavior
Constructing the tool and generating its JSON schema should succeed when its dependencies are installed.
Failure scenario
Any agent setup that instantiates the tool, or that lists it for an LLM (schema generation), crashes at construction time rather than running. Because the crash is at construct or bind time, it takes down the whole tool registration path, not just a single call.
Root cause and suggested fix
PR #781 moved from rai_perception.tools import GetGrabbingPointTool out of a runtime import and into an if TYPE_CHECKING: block to break a circular import. That leaves the Pydantic annotation unresolvable at runtime. Two workable fixes:
- Import
GetGrabbingPointTool at runtime (guarded as it was before), or
- Keep the
TYPE_CHECKING import and call GetObjectPositionsTool.model_rebuild() once the real type is importable.
The current test suite does not catch this because it builds the tool with model_construct(), which bypasses validation and the fully-defined check. A test that uses the normal constructor (or calls model_json_schema()) would reproduce it.
Version
main at commit e54f8ca995dc80cc3e058171500948a24129b302.
Automated report: this issue was produced and filed automatically, with no human review before posting. Two independent checks agreed it is a real bug, but if it misreads the code please say so and we will close it.
Found while running Ito (AI code review that runs your application, free for open source) against recently merged PRs. Full analysis.
Describe the bug
On the current
main(commite54f8ca995dc80cc3e058171500948a24129b302), constructingGetObjectPositionsToolfromrai.tools.ros2.manipulation.custom(also re-exported fromrai.tools.ros2) raises:The tool subclasses a Pydantic model and declares the field
get_grabbing_point_tool: "GetGrabbingPointTool", butGetGrabbingPointToolis imported only inside anif TYPE_CHECKING:block, so the forward reference is never resolvable at runtime and nomodel_rebuild()call exists anywhere in the package. The failure happens even when the perception package is installed.Relevant code on the default branch:
rai/src/rai_core/rai/tools/ros2/manipulation/custom.py
Lines 34 to 35 in e54f8ca
rai/src/rai_core/rai/tools/ros2/manipulation/custom.py
Line 343 in e54f8ca
To Reproduce
raiwith perception support sorai_perceptionis importable.from rai.tools.ros2 import GetObjectPositionsTool, GetGrabbingPointToolGetObjectPositionsTool(connector=connector, get_grabbing_point_tool=GetGrabbingPointTool(connector=connector)).PydanticUserErrorabove. Generating the tool schema withGetObjectPositionsTool.model_json_schema()(which LangChain does when binding the tool to an LLM) fails the same way.The repository's own callers construct the tool this way and hit the same error:
examples/rosbot-xl-demo.py,examples/manipulation_common.py, andsrc/rai_bench/rai_bench/manipulation_o3de/benchmark.py.Expected behavior
Constructing the tool and generating its JSON schema should succeed when its dependencies are installed.
Failure scenario
Any agent setup that instantiates the tool, or that lists it for an LLM (schema generation), crashes at construction time rather than running. Because the crash is at construct or bind time, it takes down the whole tool registration path, not just a single call.
Root cause and suggested fix
PR #781 moved
from rai_perception.tools import GetGrabbingPointToolout of a runtime import and into anif TYPE_CHECKING:block to break a circular import. That leaves the Pydantic annotation unresolvable at runtime. Two workable fixes:GetGrabbingPointToolat runtime (guarded as it was before), orTYPE_CHECKINGimport and callGetObjectPositionsTool.model_rebuild()once the real type is importable.The current test suite does not catch this because it builds the tool with
model_construct(), which bypasses validation and the fully-defined check. A test that uses the normal constructor (or callsmodel_json_schema()) would reproduce it.Version
mainat commite54f8ca995dc80cc3e058171500948a24129b302.Automated report: this issue was produced and filed automatically, with no human review before posting. Two independent checks agreed it is a real bug, but if it misreads the code please say so and we will close it.
Found while running Ito (AI code review that runs your application, free for open source) against recently merged PRs. Full analysis.