Form next requested slot incorrectly asked in Rasa 3.0, although it was removed from required slots

[iuliacotaga]

Rasa Open Source version

3.0.1

Rasa SDK version

No response

Rasa X version

No response

Python version

3.8

What operating system are you using?

Windows

What happened?

This was confirmed as an issue based in this forum discussion:

https://forum.rasa.com/t/form-next-requested-slot-incorrectly-asked-in-rasa-3-0-although-it-was-removed-from-required-slots/50020

All the relevant info related to this case can be found in the discussion.

Command / Request

No response

Relevant log output

No response

Defintion of done

• Understand why it has changed between 2.8 and 3.0
• Ask user what they want to achieve with this behavior
• Decide if this behavior is what we actually want to support

[sara-tagger]

Thanks for the issue, @dakshvar22 will get back to you about it soon!

You may find help in the docs and the forum, too 🤗

[sara-tagger]

Thanks for the issue, @ancalita will get back to you about it soon!

You may find help in the docs and the forum, too 🤗

[ancalita]

@iuliacotaga Thanks for opening this issue - we're trying to understand the motivation(s) and use cases for removing a form required slot defined in the domain via the FormValidationAction custom action, could you please provide more context?

[iuliacotaga]

The list of form slots defined in the domain contains all the possible slots that need to be filled in.
However, the actual slots that need to be filled in are dynamically decided during conversation. Based on specific user answer, certain slot may not further make sense, therefore it is removed from required_slots list in order to avoid being requested as the next slot.

[ancalita]

I see, this seems to be the reverse of dynamic form behaviour (the recommended way would be specifying the mininum required slots in the domain, then adding slots depending on other slot values via FormValidationAction). Have you tried this but it did not meet your use-case? @iuliacotaga

[iuliacotaga]

The opposite logic of adding slots instead of removing them would not properly fit the requirements.
The scenario of dynamically adjusting the form slots list works fine in 2.x version, including for the remove case. This flexibility really helps on supporting various scenarios. Is there any reason for not continuing to have it? Thanks.

[ancalita]

I will discuss this internally as we're not entirely sure the remove case was intentionally designed in 2.x.

[ancalita]

I will discuss this internally

To help us on this front, would you be able to share your requirements and give more details about the problem you're trying to solve? @iuliacotaga

[ancalita]

@iuliacotaga I found the source of the bug, it's actually introduced by the domain_slots.remove(slot_to_remove line in your custom action. Because you're modifying domain_slots, this has a knock-on effect further in this line here where it cedes control to Rasa to request the next slot (and Rasa looks at the form's required slots as defined in the domain - this is how it has been in 2.x also).

I would recommend copying domain_slots in a new variable, modify that new list/variable and then return the modified new list, I've just tested with a bot and the fix works, form1_slot2 doesn't get requested. Hope this helps! I'll look to see if I can make the docs clearer for this example.

cc'ing @TyDunn

[ancalita]

Solution updated in docs via merged PR #10734