Unable to start Transaction Service locally

[distributedstatemachine]

Description

I am unable to start the the safe tx service by following the instructions to run it locally.

Steps to reproduce

• Clone the repo
• cd scripts && sh run_locally.sh

Expected Behaviour

• All containers start

Actual Behaviour

==> 08:05:22 ==> Creating super-user for Safe Transaction Service... (may take a while)
service "txs-web" is not running container #1

On examiing the container logs

ubuntu@ip-172-31-95-221:~/safe-infrastructure/scripts$ docker container logs cec548c5bbe4
==> 08:02:46 ==> Check RPC connected matches previously used RPC... 
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/django/db/backends/utils.py", line 89, in _execute
    return self.cursor.execute(sql, params)
psycopg2.errors.UndefinedTable: relation "history_chain" does not exist
LINE 1: SELECT "history_chain"."chain_id" FROM "history_chain" LIMIT...
                                               ^

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/app/manage.py", line 30, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python3.10/site-packages/django/core/management/__init__.py", line 442, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python3.10/site-packages/django/core/management/__init__.py", line 436, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python3.10/site-packages/django/core/management/base.py", line 412, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/python3.10/site-packages/django/core/management/base.py", line 458, in execute
    output = self.handle(*args, **options)
  File "/app/safe_transaction_service/history/management/commands/check_chainid_matches.py", line 15, in handle
    chain = Chain.objects.get()  # Only one element in the table
  File "/usr/local/lib/python3.10/site-packages/django/db/models/manager.py", line 87, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/django/db/models/query.py", line 633, in get
    num = len(clone)
  File "/usr/local/lib/python3.10/site-packages/django/db/models/query.py", line 380, in __len__
    self._fetch_all()
  File "/usr/local/lib/python3.10/site-packages/django/db/models/query.py", line 1881, in _fetch_all
    self._result_cache = list(self._iterable_class(self))
  File "/usr/local/lib/python3.10/site-packages/django/db/models/query.py", line 91, in __iter__
    results = compiler.execute_sql(
  File "/usr/local/lib/python3.10/site-packages/django/db/models/sql/compiler.py", line 1562, in execute_sql
    cursor.execute(sql, params)
  File "/usr/local/lib/python3.10/site-packages/django/db/backends/utils.py", line 67, in execute
    return self._execute_with_wrappers(
  File "/usr/local/lib/python3.10/site-packages/django/db/backends/utils.py", line 80, in _execute_with_wrappers
    return executor(sql, params, many, context)
  File "/usr/local/lib/python3.10/site-packages/django/db/backends/utils.py", line 84, in _execute
    with self.db.wrap_database_errors:
  File "/usr/local/lib/python3.10/site-packages/django/db/utils.py", line 91, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/usr/local/lib/python3.10/site-packages/django/db/backends/utils.py", line 89, in _execute
    return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: relation "history_chain" does not exist
LINE 1: SELECT "history_chain"."chain_id" FROM "history_chain" LIMIT...

System Information

Linux ip-172-31-95-221 5.19.0-1025-aws #26~22.04.1-Ubuntu SMP Mon Apr 24 01:58:15 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

[AtharvDesignString]

Hello @samtvlabs , I also encountered the same problem are you able to solve it?

[moisses89]

The database is initialized for indexer worker, can you check if indexer worker is running, or is returning an error.

[Uxio0]

Indexer worker needs to run migrations before other pods, so sometimes there's a race condition and this could happen. Restarting the service should make it work