Question about Tracker Stores and Event Brokers

I’ve built a rasa assistant and recently connected it to a instance of Rasa-X that I configured using the Manual Installation tutorial found here.

I’ve updated my rasa assistant’s endpoints.yml file to use the Pika event broker to forward the rasa events to the Rasa-x instance. I suppose now I can get rid of the SQL tracker store from this endpoints.yml file because all of the data is going to be stored in the server running rasa-x now. If I delete the tracker store information from this file, will the bot just use its in-memory tracker store now, and are there any potential problems with that?

I also have another question related to this. I want to save some custom metadata to each rasa event that gets stored to the SQL database. How can I add a custom field to the data that gets sent to the pika event broker?


Hey @plurn,

You could, in theory, get rid of the SQL tracker store and use the in-memory one. The problem with this is that then you’ll run into problems if your Rasa Open Source node gets restarted, because all the conversation information will be lost. If you have multiple Rasa Open Source nodes, you may also have a problem when two different nodes try to handle the same conversation, and since each can’t access the tracker stored in the other one, you will get incorrect event predictions. So in general, it is better to have the trackers stored somewhere external, like in the SQL database.

One way of adding custom metadata to events could be via a custom action. This will only allow you to add metadata to events that the action creates though, and it will be dependent on the action being executed.

Another option would be to make the Rasa Open Source nodes forward events to queue A, but make Rasa X read events from queue B. Then, write a script that constantly consumes events from A, modifies them and then forwards them to B.

1 Like

Thanks for your reply, it’s really helpful. I have two followup questions though.

I understand the need for a permanent tracker store in the case of multiple Rasa Open Source nodes, but wouldn’t the conversation history info still be saved if I have a pika message queue forward the conversation history to the Rasa-X database? As I understand it, attaching the Rasa Open Source to the default pika message queue in the endpoints.yml from Rasa-X will forward rasa open source conversation histories to the default Rasa-X postgresql database. Is my understanding of that correct?

Also, thanks for your idea using custom actions to save metadata. Would the best way to do this be by setting a custom slot in the action, or are there other ways to add metadata in such a way that I could add a column to the conversation_event SQL table, for example?


If you have Rasa X setup + Pika then yes, technically your conversation events would not be lost, because they would always be stored in the Rasa X database. The problem is that the Rasa Open Source nodes do not have access to this database, they rely on a tracker store instead (and also, the schemas for storing the events are different). This should be clear in this diagram, note that the Tracker Store and the SQL DB (Rasa X) are separate.

For the metadata part it depends on what you want to attach metadata to:

  • If you want to attach metadata to conversations, I think setting a slot to a specific value would work.
  • If you want to attach metadata to only events generated by a custom action, then you could set each event’s metadata key to whatever you like, before returning the list of actions from run(self, ...).
  • If you want to set metadata for absolutely all events in the conversation, then I think the idea I shared before is still the best approach.

You could add a column to conversation_event. This use case is not supported though, so you might unexpected problems in the future. Maybe creating a new table with a foreign key pointing at conversation_event could work as well.