fix(hotel_receptionist): stop the restaurant flow implying a table it never reserved - #6800
fix(hotel_receptionist): stop the restaurant flow implying a table it never reserved#6800u9g wants to merge 2 commits into
Conversation
decline_phone_number_capture completed the task with a bare ToolError, indistinguishable from any other failure, so a caller that needs to react to a refusal (rather than to a crash) had only the message text to match on. PhoneNumberCaptureDeclinedError subclasses ToolError with the same message, so existing callers are unaffected.
… never reserved A caller who won't give a phone number ended the flow with a bare ToolError, which start_restaurant_booking let propagate; the receptionist then read a failed tool call as a booked table and spoke a confirmation. The flow now completes with RestaurantReservationNotCreatedError, which the tool catches and reports as a non-reservation, and the phone dialog is told to decline rather than stall when the caller has no number.
1c40f75 to
da1665f
Compare
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| class PhoneNumberCaptureDeclinedError(ToolError): | ||
| def __init__(self, reason: str) -> None: | ||
| super().__init__(f"couldn't get the phone number: {reason}") | ||
| self._reason = reason | ||
|
|
||
| @property | ||
| def reason(self) -> str: | ||
| return self._reason |
There was a problem hiding this comment.
🟡 New public error class ships without documentation
The newly added public error type is exported in the package's public API (PhoneNumberCaptureDeclinedError at livekit-agents/livekit/agents/beta/workflows/phone_number.py:62) without any docstring, so it appears undocumented in the generated API docs.
Impact: Users browsing the published API reference see an undocumented error type and cannot tell when it is raised.
CONTRIBUTING.md documentation requirement for new classes
CONTRIBUTING.md states: "If writing new methods/enums/classes, document them. This project uses pdoc3 for automatic API documentation generation, and every new addition has to be properly documented." The class and its reason property (livekit-agents/livekit/agents/beta/workflows/phone_number.py:67-69) have no docstrings, and the class is exported in livekit-agents/livekit/agents/beta/workflows/__init__.py:32. By contrast, the base ToolError documents itself (livekit-agents/livekit/agents/llm/tool_context.py:124-131), and the example-side counterpart RestaurantReservationNotCreatedError does carry a docstring.
| class PhoneNumberCaptureDeclinedError(ToolError): | |
| def __init__(self, reason: str) -> None: | |
| super().__init__(f"couldn't get the phone number: {reason}") | |
| self._reason = reason | |
| @property | |
| def reason(self) -> str: | |
| return self._reason | |
| class PhoneNumberCaptureDeclinedError(ToolError): | |
| """Raised when the user explicitly declines to provide a phone number. | |
| `GetPhoneNumberTask` completes with this error (instead of a bare `ToolError`) | |
| so callers can distinguish a deliberate refusal from other failures. | |
| """ | |
| def __init__(self, reason: str) -> None: | |
| super().__init__(f"couldn't get the phone number: {reason}") | |
| self._reason = reason | |
| @property | |
| def reason(self) -> str: | |
| """Short explanation of why the user declined to provide the phone number.""" | |
| return self._reason |
Was this helpful? React with 👍 or 👎 to provide feedback.
|
Duplicate of #6801, which carries the same change plus test coverage. Closing in favor of that one. |
1 participant
A caller who won't give a phone number ended
BookRestaurantTaskwith a bareToolError, andstart_restaurant_bookinglet it propagate. The receptionist read the failed tool call as a booked table and spoke a confirmation for a reservation that was never written.Cherry-picked out of #6567, which bundles this with a lot of unrelated hotel-receptionist work.
Changes
Library —
decline_phone_number_capturecompleted the task with a bareToolError, indistinguishable from any other failure, so a caller that wants to react to a refusal (rather than to a crash) had only the message text to match on.PhoneNumberCaptureDeclinedErrorsubclassesToolErrorwith the identical message, so existing callers are unaffected.Example —
RestaurantReservationNotCreatedErroris what the restaurant flow now completes with when the phone dialog is declined.open_phone_dialogcatches the declined error and returns wording that states the outcome;start_restaurant_bookingcatches it and reports a non-reservation instead of falling through to the success string. The phone dialog also gets instructions to decline rather than stall when the caller has no number.Testing