Closed joshuasv closed 3 years ago
Hi @joshuasv, from what I can see, this actually is expected behaviour based on how you've configured your bot. Here's why:
When you're in the form in your example conversation, at 7. the ('requested_slot') == "confirm_exercise"
. So your condition in extract_confirm_exercise
is true and since the registered intent is affirm
, the slot is set to true. Any rule you might have only kicks in if the form action is rejected (you can read more about rejecting a form action here, but the gist for this context is that it will be rejected if a extraction method returns no slots).
I think the best way to achieve the behaviour you want is to make the conditions in extract_confirm_exercise
more restrictive, something like below. You'll also need a rule to kick in when utter_ask_continue
is executed (something like: continue if affirm
, exit if not).
if (not tracker.slots.get('requested_slot') == "confirm_exercise"
or tracker.latest_action_name == "utter_ask_continue"):
return {}
What do you think?
I understood the first part. Since the form is active, and confirm_exercise
is expecting an affirm
intent, when the user makes that kind of input it fills the slot marked in the requested_slot
of the bot's memory. Even when the user is answering a question that is not used to fill one of the slots of the form.
On the other hand, adding that extra conditional to the if statement doesn't solve the problem. Once the form is activated tracker.latest_action_name
is equal to health_form
, so the condition is never met for the intended purpose.
Also, I've added the following rules to my rules.yml
as per your recommendation. I think this makes the bot behavior more predictable. Thank you.
- rule: Ask continue deny
condition:
- active_loop: health_form
steps:
- action: utter_ask_continue
- intent: deny
- action: action_deactivate_loop
- active_loop: null
- action: utter_goodbye
- rule: Ask continue confirm
condition:
- active_loop: health_form
steps:
- action: utter_ask_continue
- intent: affirm
- action: health_form
- active_loop: null
- action: action_submit_form
- action: utter_slots_values
Gotcha, that's my bad with the latest_action
. Would you try:
tracker.get_last_event_for("action", exclude=["health_form"])
?
That last comment definitely was on the right track. Even though tracker.get_last_event_for("action", exclude=["health_form"])
always returned action_listen
, adding to the method skip=1
did the trick. Thank you for your time @koernerfelicia 😁✌️
Also, this problem came to me because I was doing the Udemy course to learn Rasa. Instead of using the version that they use in the video, I was trying to do it with the newer 2.5 version. And, I wasn't getting the same behaviour as in the example. So, I think this could be useful to those doing that course and want to achieve the same results.
Solution
In actions.py
add a more restrictive conditional to those extract_<slot_name>
functions that modify the bot's memory with the same intent as the one answering the utter_ask_continue
question.
if (not tracker.slots.get('requested_slot') == "confirm_exercise" or tracker.get_last_event_for(event_type="action", exclude=["health_form"], skip=1)['name'] == "utter_ask_continue"):
return {}
@joshuasv, glad that worked, thanks for your patience! And thank you, as well, for the feedback. Our team is working on updating the content to the latest Rasa version, so I'll pass it on to them.
Happy bot building! If you do get stuck again, feel free to post in the forum (https://forum.rasa.com/). You can tag me there (@felicia)
Rasa version: 2.5.0 Rasa SDK version: 2.5.0 Python version: 3.6.9 Operating system (windows, osx, ...): Linux pc 5.4.0-70-generic #78~18.04.1-Ubuntu SMP Sat Mar 20 14:10:07 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Issue: I have the following story:
And let's assume the following conversation:
As you can see, in the 7th message if the user makes an affirmation intent it answers the question proposed in the 6th message as well as the one proposed in the 4th message.
I would expect a conversation flow like this:
Is this expected behavior?
Error (including full traceback):
Command or request that led to error:
Content of configuration file (config.yml) (if relevant):
Content of domain file (domain.yml) (if relevant):
Contents of actions.py (if relevant):