Upgrade from 4.0.7 to 4.1.9 or 4.2.11: 500 errors

Wheels · January 15, 2024, 4:12pm

I’ve been upgrading from 3.5.10 today all the way up to 4.2.11.

I chose to break the upgrade up a bit to make sure all is stable:

Upgrade Process

1. Upgrade 3.5.10 to 4.0.7

This upgrade was successful and all appeared to work fine.
Scripts Run:

4.0
template migration script as specified in the extra notice

2. Upgrade from 4.0.7 to 4.2.11

This upgrade made all pages return a 500 with generic error (see below).

Scripts Run:

4.1
4.2

What I’ve Tried

Rollback to 4.1.9

This allows seatable to load and I can login, but the home page will not show any bases. The /api/v2.1/workspaces/ call returns a 500 with the same generic message as above and the home page looks like this:

Rollback to 4.0.7

This appears to be the latest stable version I can successfully run so far, though I haven’t tested very much with it yet.

Logs

I’m not seeing any error logs changing accept the normal socket-io.error.log connection failed on occasion and error.log 404 errors for /dtable-web/media/css/antd-mobile.min.css.map.

Question

Does anyone have any suggestions on debugging or ideas to get the upgrades back on a successful track?

cdb · January 15, 2024, 7:47pm

Problems like you describe are most likely connected to problems with the mariadb-database structure. Some table columns does not exist or have the wrong format.
Or you have some really strange configuration problems in dtable_web_settings.py.

Here is my advise:
Run the updates again and execute the following command to get error messages from SeaTable:

tail -f /opt/seatable/seatable-data/seatable/logs/dtable_web.log

Then try to open SeaTable webinterface. You should get any kind of error message.

Wheels · January 15, 2024, 10:36pm

Thanks for the reply @cdb. I’ll give this ago though I didn’t see anything questionable in the logs before.

One related question that might make this a little more thorough. Do you know what happens if I run the seatable.sh upgrade-sql {version} commands again?

If those are safe to re-run, I may just go version by version running them again to schema inconsistency is not an issue. I am knowledgeable of databases so if it helps.

Settings

This is a sanitized version of the dtable_web_settings.py. This is all the settings, though the values are obviously fake.

DTABLE_GOOGLE_MAP_KEY = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
EMAIL_USE_TLS = False
EMAIL_HOST = 'xxxx.xxxxxxx.xxx'     # smtp server
EMAIL_HOST_USER = 'xxxxxxxx'                # username and domain
EMAIL_HOST_PASSWORD = 'xxxxxxxxxxxxxxxx'            # password
EMAIL_PORT = 2525
DEFAULT_FROM_EMAIL = 'xxxxx@xxxxxx.xxx'
SERVER_EMAIL = 'xxxxx@xxxxxx.xxx'

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'HOST': 'db',
        'PORT': '3306',
        'USER': 'root',
        'PASSWORD': 'xxxxxxxxxxxxxxxxxxxxx',
        'NAME': 'dtable_db',
        'OPTIONS': {
            'charset': 'utf8mb4',
        },
    }
}

CACHES = {
    'default': {
        'BACKEND': 'django_pylibmc.memcached.PyLibMCCache',
        'LOCATION': 'memcached',
    },
    'locmem': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
    },
}
COMPRESS_CACHE_BACKEND = 'locmem'

SECRET_KEY = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

# for dtable-server
DTABLE_PRIVATE_KEY = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
DTABLE_SERVER_URL = 'https://xxx.xxxxxx.xxx/dtable-server/'
DTABLE_SOCKET_URL = 'https://xxx.xxxxxx.xxx/'

# for dtable-web
DTABLE_WEB_SERVICE_URL = 'https://xxx.xxxxxx.xxx/'

# for dtable-db
DTABLE_DB_URL = 'https://xxx.xxxxxx.xxx/dtable-db/'

# for dtable-storage-server
DTABLE_STORAGE_SERVER_URL = 'http://127.0.0.1:6666/'

NEW_DTABLE_IN_STORAGE_SERVER = True

# for seaf-server
FILE_SERVER_ROOT = 'https://xxx.xxxxxx.xxx/seafhttp/'

ENABLE_USER_TO_SET_NUMBER_SEPARATOR = True


PLUGINS_REPO_ID='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'

Wheels · January 15, 2024, 10:59pm

Ok, tried it and got something useful. Thank you so much for the help!

Looks like dtable_share.share_folder_id is the issue. Guessing that’s an update script I missed or some in-between version I didn’t know to run. I did run all the versions for which I saw releases in dockerhub.

[ERROR] django.request:224 log_response Internal Server Error: /api/v2.1/workspaces/
Traceback (most recent call last):
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/db/backends/mysql/base.py", line 73, in execute
    return self.cursor.execute(query, args)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/MySQLdb/cursors.py", line 206, in execute
    res = self._query(query)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/MySQLdb/cursors.py", line 319, in _query
    db.query(q)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/MySQLdb/connections.py", line 254, in query
    _mysql.connection.query(self, query)
MySQLdb.OperationalError: (1054, "Unknown column 'dtable_share.share_folder_id' in 'field list'")

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

Traceback (most recent call last):
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/core/handlers/exception.py", line 47, in inner
    response = get_response(request)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/core/handlers/base.py", line 181, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/views/decorators/csrf.py", line 54, in wrapped_view
    return view_func(*args, **kwargs)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/views/generic/base.py", line 70, in view
    return self.dispatch(request, *args, **kwargs)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/rest_framework/views.py", line 509, in dispatch
    response = self.handle_exception(exc)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/rest_framework/views.py", line 469, in handle_exception
    self.raise_uncaught_exception(exc)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/rest_framework/views.py", line 480, in raise_uncaught_exception
    raise exc
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/rest_framework/views.py", line 506, in dispatch
    response = handler(request, *args, **kwargs)
  File "/opt/seatable/seatable-server-latest/dtable-web/seahub/api2/endpoints/dtable.py", line 222, in get
    for table in shared_tables_by_user:
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/db/models/query.py", line 280, in __iter__
    self._fetch_all()
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/db/models/query.py", line 1324, in _fetch_all
    self._result_cache = list(self._iterable_class(self))
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/db/models/query.py", line 51, in __iter__
    results = compiler.execute_sql(chunked_fetch=self.chunked_fetch, chunk_size=self.chunk_size)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/db/models/sql/compiler.py", line 1175, in execute_sql
    cursor.execute(sql, params)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/db/backends/utils.py", line 66, in execute
    return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/db/backends/utils.py", line 75, in _execute_with_wrappers
    return executor(sql, params, many, context)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/db/utils.py", line 90, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/db/backends/mysql/base.py", line 73, in execute
    return self.cursor.execute(query, args)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/MySQLdb/cursors.py", line 206, in execute
    res = self._query(query)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/MySQLdb/cursors.py", line 319, in _query
    db.query(q)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/MySQLdb/connections.py", line 254, in query
    _mysql.connection.query(self, query)
django.db.utils.OperationalError: (1054, "Unknown column 'dtable_share.share_folder_id' in 'field list'")
2024-01-15 16:00:42,238 [ERROR] django.request:224 log_response Internal Server Error: /api/v2.1/workspaces/
Traceback (most recent call last):
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/db/backends/mysql/base.py", line 73, in execute
    return self.cursor.execute(query, args)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/MySQLdb/cursors.py", line 206, in execute
    res = self._query(query)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/MySQLdb/cursors.py", line 319, in _query
    db.query(q)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/MySQLdb/connections.py", line 254, in query
    _mysql.connection.query(self, query)
MySQLdb.OperationalError: (1054, "Unknown column 'dtable_share.share_folder_id' in 'field list'")

Wheels · January 16, 2024, 12:46am

And we are up. It had been a while since we ran upgrades for seatable, so here’s what we missed:

In the upgrade documentation it describes running the scripts, but isn’t clear that they need to be run on the docker machine. In addition, when running them on the host, the script simply returns with no output letting you know it couldn’t do anything, so effectively, none of the upgrade sql was run.

After getting a console to the docker instance:

docker exec -it seatable bash

then running the sql upgrade script:

/opt/seatable/scripts/seatable.sh upgrade-sql 4.1
/opt/seatable/scripts/seatable.sh upgrade-sql 4.2

the only output we received for each command was:

mysql: [Warning] Using a password on the command line interface can be insecure.

At least the warnings let us know that the script did something, so to prevent future confusion, I would recommend adding some output to the upgrade script to at least let the user know of success or failure. If this is part of an open source component, we could submit a pull request with this update if you like

Once again, thank you for the much needed point in the right direction and a great product!

rdb · January 16, 2024, 1:13am

Glad to hear!

We hear your feedback regarding the update process.

Give us a little more time. The installation and update process will be greatly simplified with SeaTable 4.3 which is scheduled to be released in a few weeks.

Wheels · January 17, 2024, 10:48pm

No problem @rdb. We know you work hard on the product and I hope our input is helpful / productive. As mentioned, we are happy to pitch in providing specific updates for docs, patches, or pull requests anywhere it would help.

Thanks again for the help @cdb !

system · January 19, 2024, 10:49pm

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.