Rasa: Rename `FormValidation` event to something "loop" related

[wochinge]

Follow up from https://github.com/RasaHQ/rasa/issues/6409 and PR https://github.com/RasaHQ/rasa/pull/6439 .

Same as we re-named the Form event, we should also re-name the FormValidation event.

Todos

• [x] do the same for FormValidation as for Form in https://github.com/RasaHQ/rasa/pull/6439
• [x] do the same for FormValidation as for Form in the SDK (see thisPR https://github.com/RasaHQ/rasa-sdk/pull/246)

@Ghostvv @akelad Please fire away with naming suggestions. As we don't validate after a Loop was re-called after an unhappy path, it makes sense to call it something like LoopExecutionAfterUnhappyPath?

[akelad]

LoopExecutionAfterUnhappyPath pls no 😂 will take a deeper look for better name suggestions

[wochinge]

UnhappyLoop? 😄

[wochinge]

I created a PR with the whole renaming logic. All which is left todo for Rasa Open Source (this doesn't handle SDK / X yet) is filling in the right name then: https://github.com/RasaHQ/rasa/pull/6468

[wochinge]

@alwx Did you continue working on this? @akelad Do you have some new name suggestions? 👀

[Ghostvv]

if you look at loops they don't have validation idea inside them. so technically, Akela's suggestion LoopExecutionAfterUnhappyPath is correct 😅😇

[wochinge]

It was mine :-D Akela was unhappy. How about shortening it to LoopUnhappyPath? We might be able to drop this event anyway once we figured out the end-to-end problems for policy predictions.

[Ghostvv]

sorry, didn't see it

[Ghostvv]

How about we keep it FormValidation for now, until we figure out tracker problems?

[Ghostvv]

LoopUnhappyPath hm... smth about it is not intuitive, but cannot formulate what

[akelad]

yeah LoopUnhappyPath doesn't sound right. What's the reason for not calling it LoopValidation again? From what I understand the event gets added to the tracker as FormValidation(False) when the user "breaks out" of a form/loop right? LoopUnhappyPath(False) seems like that would be wrong 😅

[Ghostvv]

FormValidation(False) is added when a form is predicted after a user input that is the answer to a previous question if it were in stories/rules:

- utter_ask_continue
* affirm
- FormValidation(False)
- q_form

but not here (inform is part of the form):

- utter_ask_continue
* inform
- q_form

[Ghostvv]

the problem that currently the implementation of the Loop doesn't have the notion of validation

[akelad]

yeah that part I know.

the problem that currently the implementation of the Loop doesn't have the notion of validation

as in, Loop doesn't, but Forms do right?

[Ghostvv]

yes

[akelad]

so why is the event needed for the Loop at all?

[Ghostvv]

because there is no form in tracker, rule policy, etc anymore. and this event will be added for loops as well, which a custom loop could use, however it wants

[akelad]

yeah but it does nothing for the Loop right now right? Kind of makes it hard to name it anything at all 😂

[wochinge]

Love the discussion 🎉

How about we keep it FormValidation for now, until we figure out tracker problems?

I suggest to do that. There are more important things to do the for the RC at the moment and the event name is not user facing which means we can still do this down the road.

[akelad]

haha yeah for sure, but doesn't hurt to keep the discussion going if someone has a genius idea

[wochinge]

So, what's the state on this? Happy to jump on a 5 minute call to resolve this. @akelad @Ghostvv

What's the reason for not calling it LoopValidation again? From what I understand the event gets added to the tracker as FormValidation(False) when the user "breaks out" of a form/loop right? LoopUnhappyPath(False) seems like that would be wrong 😅

yes, but it might be used in other cases in the future and that's why a general solution makes more sense imo.

[wochinge]

Ok @Ghostvv @akelad .
Sorry to push but this blocks Rasa Open Source and Rasa X:

Candidates:

• LoopUnhappyPath
• LoopValidation

Candidates I could also imagine:

• LoopBreak
• LoopExemption

I'll move forward implementing it using the name LoopUnhappyPath tomorrow in case we can't agree on another name by then.

[akelad]

What about LoopInterruption? but then I guess the event would be LoopInterruption(True) rather than LoopInterruption(False)? Otherwise it sounds wrong. If we don't wanna switch around the True/False parameters though I would prob just stick with Validation?

[wochinge]

I like LoopInterruption. Gonna use that then. I can swap the true/false stuff when deprecating the FormValidation event. Let's hear if Vova has strong feelings against this tomorrow and then we use LoopInterruption

[Ghostvv]

this event is added before returning to the loop, and is used to notify the loop that it is called after interruption. maybe LoopInterrupted(true) then?

[akelad]

Yes that’s even better!