2023-04-24 18:10:33 DEBUG rasa.core.actions.forms - Deactivating the form 'ticket_user_input_form'
/home/scripts/python_projects/rasa/rasaenv/lib/python3.7/site-packages/rasa/shared/utils/io.py:97: UserWarning: Action 'ticket_user_input_form' set slot type 'text' which it never set during the training. This can throw off the prediction. Make sure to include training examples in your stories for the different types of slots this action can return. Remember: you need to set the slots manually in the stories by adding the following lines after the action:
- action: ticket_user_input_form
- slot_was_set:
- ticket_user_input: TEST FOR INW going to ROUTER CONFIG
More info at https://rasa.com/docs/rasa/domain#slots
2023-04-24 18:10:33 DEBUG rasa.core.processor - Policy prediction ended with events '[<rasa.shared.core.events.DefinePrevUserUtteredFeaturization object at 0x7fca5c1c0990>]'.
The ticket_user_input_form takes in an input of text format. We are using this form in our project in numerous stories.
This issue occurred unexpectedly. It started to deviate from the specific story and predicted some other action, after the form was filled. We had handled this issue long back by writing slot_was_set, after active_loop: null
and action: action_home_redirect
.
To resolve this issue, we had to write the slot_was_set
before active_loop: null
for only this particular story. To give a more detailed view, the part of the story which was like this:
- action: ticket_user_input_form
- active_loop: ticket_user_input_form
- active_loop: null
- action: action_home_redirect
- slot_was_set:
- ticket_user_input: test issue
- action: action_create_element_down_sr
had to be rewritten like this to work again:
- action: ticket_user_input_form
- active_loop: ticket_user_input_form
- slot_was_set:
- ticket_user_input: test issue
- active_loop: null
- action: action_home_redirect
- action: action_create_element_down_sr
The problem with this is, what is the guarantee that numerous other stories with ticket_user_input_form will continue to work? They might break anytime. How should we handle the case in such scenarios? Is there a workaround?
Note: action_home_redirect is used after every form in our project, to allow the user to exit the form, once he types /home