Custom slot mapping is producing None value

I still have tremendous problems with custom slot mappings…

I have an entity called location and a slot called destination. Both are mentioned in my domain.yml in the according sections and destination is type: unfeaturized.

My slot mapping looks like the following:

def slot_mappings(self) -> Dict[Text, Union[Dict, List[Dict]]]:
        return {
            "destination": self.from_entity(entity="location")
        }

When i make the utterance that triggers the form, that’s the produces story:

* find_directions{"location":"Köln"}
    - directions_form
    - form{"name":"directions_form"}
    - slot{"destination":"Köln"}
    - form{"name":null}
    - slot{"requested_slot":null}

In submit() I utter a message template utter_show_directions that uses {destination}. But somehow destination is filled with None instead of the entity value location that should’ve been mapped to destination (which works as you can see in the story).

Am I doing anything wrong or is this a known bug?

In my submit() I logged the destination slot correctly. So I got a workaround where I get the slot value from the tracker and pass it as a renamed variable to the utter template.

def submit(
        self,
        dispatcher: CollectingDispatcher,
        tracker: Tracker,
        domain: Dict[Text, Any],
    ) -> List[Dict]:
        logging.info(tracker.get_slot('destination'))
        dispatcher.utter_message(
            template="utter_show_directions", destination_value=tracker.get_slot('destination'))
        return []

So utter_show_directions uses {destination_value} now.

I still think this is a bug and the first approach should work, right?

Hi @leondroidgeeks, this is a known bug for the last slot in the list. It has to do with the fact that the actual tracker sent over at the time does not contain the last slot value before it is filled on the temporary tracker, and the actual tracker is used for the submit method.

Forms will be changing a lot for the next Rasa release, so its entirely possible that this will be fixed by these changes. There is already an issue for it, so we’ll be sure to check the behavior once the new implementation is done.

For now , filling the value by grabbing it from the tracker as you have is the workaround.

1 Like

Great, thank you very much for the information. I couldn’t find any information about that on the forum, so I posted my solution here.

I already opened an issue on GitHub so you can close that one since it’s a duplicate.

Looking forward to the new Forms :blush:

1 Like