Issue with non-value-specific slot_was_set for checkpoints?

Hi folks,

I have a checkpoint that I’d like to restrict via slot_was_set so it only gets triggered when a user has a value in a specific slot. Here’s how I’ve set that up:

- story: battle
  steps:
  - checkpoint: battle_started
    slot_was_set:
    - battle_id
- intent: Battle Fallback
  - slot_was_set:
      - battle_id
  - action: my_custom_action

But… This throws the following error when I run rasa data validate:

Checkpoint 'battle_started' has an invalid slot: ['battle_id']
Items under the 'slot_was_set' key must be YAML dictionaries. The checkpoint will be skipped.
  More info at https://rasa.com/docs/rasa/stories

Based on the message, I assume it’s because it’s expecting a key/value pair there, but I don’t want to provide a specific value for it so that it behaves the same way as an intent-specific slot_was_set rule (i.e. when I don’t provide a value, it’s evaluated as being either set or not set)

Does the checkpoint-specific slot_was_set work differently than the intent-specific one? Am I unable to use it in the “set or not set” way that I’m looking to?

Thanks!

@snevi check the indentation of

  • slot_was_set: -battle_id

please http://www.yamllint.com/ or use vs code. Even the way to mention slot_was_set Training Data Format

Hi Nik,

Oh, sorry, I had a copy/paste issue in my post and you’re right that what I posted wouldn’t pass YAML validation. But this is what the story really looks like:

- story: battle
  steps:
  - checkpoint: battle_started
    slot_was_set:
      - battle_id
  - intent: Battle Fallback
  - slot_was_set:
      - battle_id
  - action: my_custom_action

It does pass YAML validation and I modeled the format after the one shown in the Checkpoints section of the docs here.

@snevi are you sure it’s your intent? - intent: Battle Fallback I mean the way you mentioning.

Sorry Nik, I’m not clear on what you’re asking.

@snevi it should be intent: battle_fallback in nlu.yml why space and uppercase? I am confused

Oh, I see! All my intent names are multi-word title case. (They’re like that since I’m porting this from DialogFlow and that’s just how they were setup there). It doesn’t seem to be a problem from what I can tell. Rasa detects the intents and sends them back to my custom action fine with the intent names in that format.

- story: battle
  steps:
  - checkpoint: battle_started
    slot_was_set:
      - battle_id
  - intent: Battle Fallback
    slot_was_set:
      - battle_id
  - action: my_custom_action

Have you tried this? after intent slot_was_set? I removed - follow same format check doc.

No, because it doesn’t appear to have any issue with the slot_was_set under the Battle Fallback intent. (And all my intents use them successfully in that format). It only appears to have an issue with the one under the checkpoint. For example, if I change it to this it works fine:

- story: battle
  steps:
  - checkpoint: battle_started
  - intent: Battle Fallback
  - slot_was_set:
      - battle_id
  - action: my_custom_action

(But I’d like to be able to restrict the checkpoint itself if possible)

@snevi I think this one is just fine.

Checkpoints can help simplify your training data and reduce redundancy in it, but do not overuse them . Using lots of checkpoints can quickly make your stories hard to understand. It makes sense to use them if a sequence of steps is repeated often in different stories, but stories without checkpoints are easier to read and write.

Yah, I read that both in the docs and in various forum posts as well but felt like since all of the intents within this particular story are going to have a slot_was_set to check the battle_id that it’d be convenient to lock them down at the checkpoint level rather than per-intent. In some ways I feel like it’d be more readable that way. If it can’t be done that way though, it’s not a big issue. I figured it was worth flagging that the behaviour of slot_was_set appears to be inconsistent when applied to a checkpoint vs. an intent though.

Hi Nik, I’d still be interested in getting an answer to my original question if that’s possible. (i.e. can I use slot_was_set for a checkpoint in the same way as I can use it for an intent? Currently it fails if I do.)

Hi @snevi sorry for the late reply! I will encourage not to use much of the checkpoints, as it basic nature is to connect two stories together. It can be either the first or the last step in a story. Further, using a lots of checkpoints can quickly make your stories hard to understand. It makes sense to use them if a sequence of steps is repeated often in different stories, on the otherhand stories without checkpoints are easier to read and write. Even, using lots of checkpoints can quickly make your example stories hard to understand, and even slow down your training.

Tip: I’d suggest not to use checkpoints, but If you want to strict your stories, you can go ahead. But, user can break the flow by giving an intent that is not expected. How you will deal that scenario? If the user says “Hey, how are you” two times then the flow breaks and the bot gets unpredictable and confused.

- story: battle
  steps:
  - checkpoint: battle_started
   # This checkpoint should only apply if slots are set to the specified value
    slot_was_set:
      - battle_id: null or with some key value
  - intent: Battle Fallback
  - action: my_custom_action

I hope it will clear some of your doubts? Good luck!