1.30.0 - docker container fails to start

Technical Help
1

I have a test instance of Baserow hosted on Unraid (docker single image - default config)
hardware is AMD 5000 series with 32+GB of RAM.

Upgrade to 1.30.0 causes the container to be unable to start (it reports starting, but ultimately fails after about 30 secs)

Has anyone reported similar issues with 1.30.0?

2

Here is a piece of log which seems relevant.

[BACKEND][2024-12-19 15:29:37] return self.cursor.execute(sql)
[BACKEND][2024-12-19 15:29:37] ^^^^^^^^^^^^^^^^^^^^^^^^
[BACKEND][2024-12-19 15:29:37] django.db.utils.ProgrammingError: column “include_all_select_options” of relation “database_formviewfieldoptions” already exists
[BASEROW-WATCHER][2024-12-19 15:29:37] Waiting for Baserow to become available, this might take 30+ seconds…
[BACKEND][2024-12-19 15:29:37]
2024-12-19 15:29:37,543 WARN exited: backend (exit status 1; not expected)
2024-12-19 15:29:37,543 WARN exited: backend (exit status 1; not expected)
2024-12-19 15:29:37,543 INFO gave up: backend entered FATAL state, too many start retries too quickly
2024-12-19 15:29:37,543 INFO gave up: backend entered FATAL state, too many start retries too quickly
2024-12-19 15:29:37,543 INFO reaped unknown pid 704 (exit status 0)
2024-12-19 15:29:37,543 INFO reaped unknown pid 704 (exit status 0)
Baserow was stopped or one of it’s services crashed, see the logs above for more details.

3

reverting back to 1.29.3 solves the issue - also, one of the develop-latest builds from end of last week did not have this issue either. This happened with the Tue. release.

4

Is it a correct assumption that you used some development baserow versions before?

It could be that a mistake re migration files was made but later corrected and you applied a migration that you shouldn’t have by using this problematic version.

The correct option would probably be to undo that migration. Which versions specifically you had deployed?

5

what exactly do you mean by migration files?
(I have not been migrating the baserow/data folder for this instance as far as I remember)

re: specific development version

  • probably most during the last two weeks - I’ve not been keeping track of this, as the affected instance is purely for first feature/bugfix tests and is totally expendable. However, It would be good to know if that happened because I did sth wrong or is it just something that can occur with development builds. (the first version installed, I think, was 1.26 or 1.27)
6

Hey @dev-rd, are you running the unstable develop latest images on your server? We changed the order of an automated database migration on our side, which hasn’t been released publicly, and this is causing the problem. I recommend to only use the develop latest images if you’re okay with these kinds of situations happening from time to time.

In order to fix it, you would need to connect to your Baserow PostgreSQL database, open the django_migrations table, and rename the 0174_formviewfieldoptions_include_all_select_options_and_more entry to 0175_formviewfieldoptions_include_all_select_options_and_more.

Or if the data is expendable, then you can just wipe the PostgreSQL database, and start from scratch. You would lose all your data, though.

Please note that you have not done anything wrong. This would never had happened if you use the stable release tags.

7

Thanks for the info @bram - this particular instance is expendable.
I have one instance I’d like to keep, though (I have not updated that one yet). It used the “develop latest” tag around September - would you recommend changing the django_migrations table in that one?

8

Hey @dev-rd, if it’s using the develop latest image from around September, then this problem should not have been introduced, and you can safely upgrade to either the latest develop-latest image or 1.30.1. The problem only occurred if you were using the develop latest from about 2 weeks ago and then try to upgrade.