Rasa: Stories with only a start checkpoint and an end checkpoint are ignored during training

[nbeuchat]

Rasa version: 1.1.8

Python version: 3.6

Operating system (windows, osx, ...): Ubuntu (using WSL)

Issue:
Stories with only a start checkpoint and an end checkpoint are ignored during training. The story looks like this:

## within form interest blank
> within_form_apartment_interest
> back_from_within_form_apartment_interest

Context:
To give you some context. In order to deal with different questions that could happen during a form without having to create the full story for each of them, I have created different stories connected by two checkpoints within_form_apartment_interest and back_from_within_form_apartment_interest:

• A story to start the form (in practice, many stories)
• A story after the form (in pracice, many stories as well)
• Several stories within the form. For example, a user might ask why we need this field, or ask another question.

Questions are handled with the "within form stories" as:

## explain - explain why we need this field
> within_form_apartment_interest
* explain
  - action_explain
  - form_apartment_interest
> back_from_within_form_apartment_interest

## ask_available - data is set
> within_form_apartment_interest
* ask_available
  - action_answer_available
  - form_apartment_interest
> back_from_within_form_apartment_interest

## within form interest blank (happy path)
> within_form_apartment_interest
> back_from_within_form_apartment_interest

The problem is that I also need one story where nothing wrong happens for the "happy path" to work. Unfortunately, this story only contains checkpoints and is not taken into account.

These checkpoints are connected to the following stories (form beginning and after form):

## beginning of form
  ...
* some_intent
      - form_apartment_interest
      - form{"name": "form_apartment_interest"}
  > within_form_apartment_interest

## after form (there are multiple of these)
  > back_from_within_form_apartment_interest
      - form{"name": null}
      - utter_thanks

Error (including full traceback):
N/A

Command or request that led to error:
N/A

[sara-tagger]

Thanks for raising this issue, @akelad will get back to you about it soon✨

Please also check out the docs and the forum in case your issue was raised there too 🤗

[akelad]

@Ghostvv is that a bug with the generator code?

[Ghostvv]

As far as I remember this is intended behavior. @tmbo do you remember why?

[tmbo]

I don't remember a specific reason why that is the case. the issue might be the following: The checkpoints in a case like this:

## within form interest blank
> within_form_apartment_interest
> back_from_within_form_apartment_interest

Are probably interpreted as start checkpoints. So the resulting block will have two start checkpoints and no end checkpoints (technically it will have an end checkpoint, the default one END).

This would mean that the back_from_within_form_apartment_interest checkpoint will just be ignored as a start checkpoint (since there is no other story that uses this as an end checkpoint, therefore this block can not be concatenated to something using this start checkpoint).

For the within_form_apartment_interest checkpoint this should mean that any block that ends with this checkpoint will reach the story end immediately. E.g. combining the above story block with

## beginning of form
* some_intent
      - form_apartment_interest
      - form{"name": "form_apartment_interest"}
  > within_form_apartment_interest

will lead to the following story:

## beginning of form
* some_intent
      - form_apartment_interest
      - form{"name": "form_apartment_interest"}

[nbeuchat]

Thanks, that's very helpful to understand. So, if I get it correctly, the following story is valid?

# story with many checkpoints
> start_checkpoint_1
> start_checkpoint_2
> start_checkpoint_3
* some_intent
- utter_something
> end_checkpoint_1
> end_checkpoint_2

where any story ending with > start_checkpoint_1, > start_checkpoint_2, or > start_checkpoint_3 would lead to this story block?

If that's the case, then it makes sense that a story block with only checkpoints not have any end checkpoints. Although maybe the last checkpoint should always be an exit?

[tmbo]

Yes the one you just posted will work as you think it would.

Although maybe the last checkpoint should always be an exit?

yes prob makes more sense than the interpretation we currently have for a story like the one you posted.

[Ghostvv]

Although maybe the last checkpoint should always be an exit?

I'm not sure about that. What if there're three checkpoints? Which one are starting, which are ending? What if you want to have many starting ones that lead to an end?

[nbeuchat]

I'm not sure about that. What if there're three checkpoints? Which one are starting, which are ending? What if you want to have many starting ones that lead to an end?

Maybe having an explicit way of setting which ones are start or end?

[Ghostvv]

I like the simplicity of current version though. It seems to me that it's not too difficult to factor out some action between these checkpoints.

[tmbo]

ok, I guess the question is more: do we actually need these checkpoint only stories. I mean you could very well, instead of having this "glue story" just use the checkpoint directly.

so instead of

## ask_available - data is set
> within_form_apartment_interest
* ask_available
  - action_answer_available
  - form_apartment_interest
> back_from_within_form_apartment_interest

## within form interest blank (happy path)
> within_form_apartment_interest
> back_from_within_form_apartment_interest

## after form (there are multiple of these)
  > back_from_within_form_apartment_interest
      - form{"name": null}
      - utter_thanks

it would just be

## ask_available - data is set
> within_form_apartment_interest
* ask_available
  - action_answer_available
  - form_apartment_interest
> back_from_within_form_apartment_interest

## after form (there are multiple of these)
  > within_form_apartment_interest
  > back_from_within_form_apartment_interest
      - form{"name": null}
      - utter_thanks

or is there any reason why this wouldn't work?

[nbeuchat]

I love that approach @tmbo, that would definitely work for our use case. I was actually not aware before this thread that we could have multiple in and out checkpoints.

[Ghostvv]

I'll close the issue for now