No response from Rasa X assistant in conversations Tab

[PTRKDY]

Hi community,

I’ve got a completed assistant and I’m moving on to Rasa X deployment to start getting testing and training feedback.

I’ve successfully followed the docker-compose installation guide and I’m running it in development for now to debug everything - I’ve run into an issue.

Docker-compose up runs successfully - no errors.

I can successfully go to http://localhost:80/ which takes me to Rasa X login, can login and follow the steps to integrate with a test repo with a super basic rasa repo in it, and I was able to train a model - so lots of the UI and container setup appears to function very smoothly.

However, once I’m at this step and I want to talk to my assistant in the conversation tab, the system seems to hang with the triple dot “waiting for response” image from the rasa side of the conversation. I’ve tested real time, interactive mode, plus resetting the conversation - and I don’t seem to be able to get a response from the bot using the project and model I’m using (which is a pretty basic bot, just out of rasa init plus one custom action) - should be no issues with this lightweight project.

So to summarize:

• Rasa X working
• docker-compose up working
• git integration via SSH working
• basic rasa project with no known issues (rasa init & train)
• can also successfully train in the rasa UI
• cannot get a response from Rasa X conversations tab

At the same time as the first initiation of this conversation, I see the logs in the following docker-compose logs.

rasa-production_1 | /opt/venv/lib/python3.7/site-packages/rasa/shared/utils/io.py:93: UserWarning: The model at ‘None’ could not be loaded. Error: http://rasa-x:5002/api/projects/default/models/tags/production

rasa-production_1 | /opt/venv/lib/python3.7/site-packages/rasa/shared/utils/io.py:93: UserWarning: Agent could not be loaded with the provided configuration. Load default agent without any model.

rasa-production_1 | /opt/venv/lib/python3.7/site-packages/rasa/shared/utils/io.py:93: UserWarning: No policy ensemble or domain set. Skipping action prediction and execution.

rasa-production_1 | More info at Policies

rasa-production_1 | /opt/venv/lib/python3.7/site-packages/rasa/shared/utils/io.py:93: UserWarning: No policy ensemble or domain set. Skipping action prediction.You should set a policy before training a model.

I am wondering the following: Do I need to tag the model for “rasa-production” to be able to talk to the assistant in the Rasa X UI correctly? I’m not personally sure if the response comes from the rasa-worker or the rasa-production images as I don’t understand the internals of the setup yet, and I’m a bit stuck.

Or alternatively is there another reason the system is not providing a response?

Any assistance would be greatly appreciated - very close to being able to deploy Rasa X and invite test users - stuck on this hurdle!

Thanks, Patrick

[PTRKDY]

I would like to document resources I am finding as I debug this.

Firstly, there appears to be a bug filed for this behavior: Rasa X - forever no response when chatting · Issue #7629 · RasaHQ/rasa · GitHub

Secondly, there seems to be an old conversation from last year, however the similarity of the described issue doesn’t seem to exactly match my issue. Rasa X not working properly

Things I have tried today:

• set RASA_HOME environment var
• switch tracker store to REDIS instead of DB in docker-compose up
• tried to debug mode rabbit as the pika handoff seems to be where the system stalls, but can’t seem to work out the correct syntax of the command statement for now [rabbitmqctl set_log_level debug] fails

This is where I get up to when the system hangs:

rasa-production_1  | 2021-02-03 01:32:22 DEBUG    rasa.core.brokers.pika  - Published Pika events to exchange 'rasa-exchange' on host 'rabbit':

Restarting the containers seems to bring up messages in the NLU inbox that weren’t in there before - so this could be related to rabbit.

Any additional advice or assistance would be appreciated - thanks! Patrick

[PTRKDY]

I managed to bypass the issue by upgrading rabbit mq version in docker image and using redis as a tracker instead of SQL, and then also using latest version of rasa X and rasa (0.35 & 2.2.0).

I got this working on local and now I’m working on server deploy (which seems to have a few more steps to debug).

[PTRKDY]

The error message I keep getting is:

ValueError: Error when trying to expand the environment variables in '${RASA_X_USERNAME:-admin}'. Please make sure to also set these environment variables: '['${RASA_X_USERNAME:-admin}']'.

I have:

• set the environment variable via export as “admin”
• I’ve also added to .env file as “admin”

Does this git sync script expect a different value? It is not picking up either the env file or the export value

Stuck here now. Thanks, Patrick

[PTRKDY]

Below is current error in:

• Rasa X 0.35
• Rasa 2.2.0

No matter how I set the environment variable, rasa does not accept it and errors out on git syncing the project directory.

Have tried:

• .env file
• export env var
• manually set env var in docker-compose

I traced it to here: https://github.com/RasaHQ/rasa/blob/main/rasa/shared/utils/io.py#L311

• rasa-x_1 | Job “run_background_synchronization (trigger: cron[minute=‘*’], next run at: 2021-02-03 09:45:00 UTC)” raised an exception
• rasa-x_1 | Traceback (most recent call last):
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/apscheduler/executors/base.py”, line 125, in run_job
• rasa-x_1 | retval = job.func(*job.args, **job.kwargs)
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/rasax/community/services/integrated_version_control/git_service.py”, line 131, in run_background_synchronization
• rasa-x_1 | loop.run_until_complete(git_service.synchronize_project(force_data_injection))
• rasa-x_1 | File “uvloop/loop.pyx”, line 1456, in uvloop.loop.Loop.run_until_complete
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/rasax/community/services/integrated_version_control/git_service.py”, line 1114, in synchronize_project
• rasa-x_1 | return await self._force_inject_latest_remote_changes()
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/rasax/community/services/integrated_version_control/git_service.py”, line 1174, in _force_inject_latest_remote_changes
• rasa-x_1 | await self._inject_data()
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/rasax/community/services/integrated_version_control/git_service.py”, line 1146, in _inject_data
• rasa-x_1 | await rasax.community.initialise.inject_files_from_disk(
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/rasax/community/initialise.py”, line 350, in inject_files_from_disk
• rasa-x_1 | inject_domain(
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/rasax/community/initialise.py”, line 185, in inject_domain
• rasa-x_1 | if not rasa.shared.core.domain.Domain.is_domain_file(
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/rasa/shared/core/domain.py”, line 1582, in is_domain_file
• rasa-x_1 | content = rasa.shared.utils.io.read_yaml_file(filename)
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/rasa/shared/utils/io.py”, line 368, in read_yaml_file
• rasa-x_1 | return read_yaml(read_file(filename, DEFAULT_ENCODING))
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/rasa/shared/utils/io.py”, line 349, in read_yaml
• rasa-x_1 | return yaml_parser.load(content) or {}
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/ruamel/yaml/main.py”, line 343, in load
• rasa-x_1 | return constructor.get_single_data()
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py”, line 113, in get_single_data
• rasa-x_1 | return self.construct_document(node)
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py”, line 123, in construct_document
• rasa-x_1 | for _dummy in generator:
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py”, line 723, in construct_yaml_map
• rasa-x_1 | value = self.construct_mapping(node)
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py”, line 440, in construct_mapping
• rasa-x_1 | return BaseConstructor.construct_mapping(self, node, deep=deep)
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py”, line 255, in construct_mapping
• rasa-x_1 | value = self.construct_object(value_node, deep=deep)
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py”, line 146, in construct_object
• rasa-x_1 | data = self.construct_non_recursive_object(node)
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py”, line 181, > * in construct_non_recursive_object
• rasa-x_1 | data = constructor(self, node)
• rasa-x_1 | File “/usr/local/lib/python3.8/dist-packages/rasa/shared/utils/io.py”, line 311, in env_var_constructor
• rasa-x_1 | raise ValueError(
• rasa-x_1 | ValueError: Error when trying to expand the environment variables in ‘${RASA_X_USERNAME:-admin}’. Please make sure to also set these environment variables: ‘[’${RASA_X_USERNAME:-admin}‘]’.

[PTRKDY]

I’ve reverted to local installation on Ubuntu server as the docker-compose still seems fragile/broken and have not had a response on this thread for several days.

When installing Rasa X using the local installation method, pip installation is incredibly slow to resolve the download - is there any additional commands to use or techniques to speed it up? It is constantly hanging on downloading dependencies.

I’m installing on AWS ec2 server, using the following command:

pip3 install --cache-dir /mnt/pip-cache rasa-x --extra-index-url https://pypi.rasa.com/simple

The cache is helping on subsequent retries, but timing out wit the following messages:

INFO: pip is looking at multiple versions of hyperframe to determine which version is compatible with other requirements. This could take a while.

INFO: pip is looking at multiple versions of hpack to determine which version is compatible with other requirements. This could take a while.

INFO: pip is looking at multiple versions of hyperframe to determine which version is compatible with other requirements. This could take a while.

INFO: This is taking longer than usual. You might need to provide the dependency resolver with stricter constraints to reduce runtime. If you want to abort this run, you can press Ctrl + C to do so.

So to summarize:

• Rasa X local install times out on AWS EC2
• Rasa X docker-compose is fragile and throws errors for environmental variables even when they are present or configured

[akelad (Akela Drissner)]

Hi @PTRKDY, sorry for not getting back to you sooner, I missed this. The recommended way of installing Rasa X on a VM is either with docker compose, or with kubernetes. I think the installation went fine for you from the looks of it, it’s just that git is having issues syncing. Can you try installing 0.35.1? There was a known issue with the git connection which was resolved in this version.