Row Count job crashes if table deleted during execution

Describe the problem

The row count job crashes with the following stack if I believe a table is deleted during execution:

UndefinedTable: relation "database_table_48661" does not exist
LINE 1: SELECT COUNT(*) AS "__count" FROM "database_table_48661" WHE...
                                          ^

  File "django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)

ProgrammingError: relation "database_table_48661" does not exist
LINE 1: SELECT COUNT(*) AS "__count" FROM "database_table_48661" WHE...
                                          ^

  File "baserow/contrib/database/table/tasks.py", line 15, in run_row_count_job
    TableHandler.count_rows()
  File "baserow/contrib/database/table/handler.py", line 562, in count_rows
    count = table.get_model(field_ids=[]).objects.count()
  File "django/db/models/manager.py", line 85, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "django/db/models/query.py", line 412, in count
    return self.query.get_count(using=self.db)
  File "django/db/models/sql/query.py", line 528, in get_count
    number = obj.get_aggregation(using, ['__count'])['__count']
  File "django/db/models/sql/query.py", line 513, in get_aggregation
    result = compiler.execute_sql(SINGLE)
  File "django/db/models/sql/compiler.py", line 1175, in execute_sql
    cursor.execute(sql, params)
  File "django/db/backends/utils.py", line 66, in execute
    return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
  File "django/db/backends/utils.py", line 75, in _execute_with_wrappers
    return executor(sql, params, many, context)
  File "django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)
  File "django/db/utils.py", line 90, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)

Solution

We should probably make the inner counting loop handle the situation if the table isn't there somehow. We have to be careful I guess to not accidentally swallow a ton of other errors that might occur for a different reason. If thats hard then perhaps the job crashing out like this is actually just fine and we can just close this issue? Not sure!