Unknown error when adding new rows, changing field name and editing formulas

[gabrielle]

Hello,

I am using Baserow self-hosted with Cloudron, the latest update has been deployed.

I’ve been adding data and making my base architecture evolve quite a bit these past couple of days and I run into the following issues:

• Can not add rows to a given table (it works with other tables), I tried adding them manually or importing a CSV, both result in the dreaded “Unknown error”.
• I can no longer change some field names in some tables (fine in others)
• I can no longer edit formulas in some tables (fine in others), if I break the formula as 1 function per field it works, but putting the full one in one field doesn’t save and gives the “Unknown error”.

I’ve checked the usage graphs in Cloudron: I am well below the limit and still have a couple of free Go. I’ve also given extra memory to Postgresql, I run below 30%.

I seem to run into similar issues as this thread.

At some point a couple of days ago, I could no longer access my app or sometimes just a given table. I tried restarting it, restoring it from a backup, nothing worked. The morning after, everything was fine…

Could someone please point me to what I should do to fix these issues?
Is there a way to remap the entire base so it no longer struggles?

Thank you for your help

Here are the logs when I tried adding new rows to the problematic table:

Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - JobHandler.run(job)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - R = retval = fun(*args, **kwargs)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - _, dependant_fields = self.update_dependencies_of_rows_created(
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - _, error_report = action_type_registry.get_by_type(
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - created_rows, creation_report = self.create_rows(
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - created_rows, creation_report = self.create_rows_by_batch(
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - created_rows, error_report = RowHandler().import_rows(
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - cursor = super().execute_sql(result_type)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - cursor.execute(sql, params)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - out = job_type.run(job, progress)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - qs.annotate(**annotations)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - raise dj_exc_value.with_traceback(traceback) from exc_value
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - raise ex
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - raise ex
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - raise ex
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - raise ex
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - raise ex
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - result = wrapped_func(*args, **kwargs)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - result = wrapped_func(*args, **kwargs)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - result = wrapped_func(*args, **kwargs)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - result = wrapped_func(*args, **kwargs)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - result = wrapped_func(*args, **kwargs)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - return executor(sql, params, many, context)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - return self._execute_with_wrappers(
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - return self.cursor.execute(sql, params)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - return self.force_create_rows(
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - return self.run(*args, **kwargs)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - rows = query.get_compiler(self.db).execute_sql(CURSOR)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - update_collector.apply_updates_and_get_updated_fields(field_cache)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - updated_rows += self._execute_pending_update_statements(
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - updated_rows_count = self._update_statement_collector.execute_all(
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - updated_rows_count = self.apply_updates(field_cache)
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - with self.db.wrap_database_errors:
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/contrib/database/fields/dependencies/update_collector.py”, line 139, in execute_all
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/contrib/database/fields/dependencies/update_collector.py”, line 217, in _execute_pending_update_statements
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/contrib/database/fields/dependencies/update_collector.py”, line 399, in apply_updates
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/contrib/database/fields/dependencies/update_collector.py”, line 415, in apply_updates_and_get_updated_fields
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/contrib/database/file_import/job_types.py”, line 175, in run
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/contrib/database/rows/actions.py”, line 264, in do
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/contrib/database/rows/handler.py”, line 1173, in force_create_rows
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/contrib/database/rows/handler.py”, line 1262, in create_rows
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/contrib/database/rows/handler.py”, line 1305, in update_dependencies_of_rows_created
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/contrib/database/rows/handler.py”, line 1464, in create_rows_by_batch
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/contrib/database/rows/handler.py”, line 1593, in import_rows
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/core/jobs/handler.py”, line 73, in run
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/core/jobs/tasks.py”, line 33, in run_async_job
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/core/telemetry/utils.py”, line 68, in _wrapper
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/core/telemetry/utils.py”, line 68, in _wrapper
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/core/telemetry/utils.py”, line 68, in _wrapper
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/core/telemetry/utils.py”, line 68, in _wrapper
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/core/telemetry/utils.py”, line 68, in _wrapper
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/core/telemetry/utils.py”, line 72, in _wrapper
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/core/telemetry/utils.py”, line 72, in _wrapper
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/core/telemetry/utils.py”, line 72, in _wrapper
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/core/telemetry/utils.py”, line 72, in _wrapper
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/backend/src/baserow/core/telemetry/utils.py”, line 72, in _wrapper
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/env/lib/python3.10/site-packages/celery/app/trace.py”, line 453, in trace_task
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/env/lib/python3.10/site-packages/celery/app/trace.py”, line 736, in protected_call
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/env/lib/python3.10/site-packages/django/db/backends/utils.py”, line 100, in _execute
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/env/lib/python3.10/site-packages/django/db/backends/utils.py”, line 105, in _execute
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/env/lib/python3.10/site-packages/django/db/backends/utils.py”, line 79, in execute
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/env/lib/python3.10/site-packages/django/db/backends/utils.py”, line 92, in _execute_with_wrappers
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/env/lib/python3.10/site-packages/django/db/models/query.py”, line 1253, in update
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/env/lib/python3.10/site-packages/django/db/models/sql/compiler.py”, line 1562, in execute_sql
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/env/lib/python3.10/site-packages/django/db/models/sql/compiler.py”, line 1990, in execute_sql
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - File “/app/code/env/lib/python3.10/site-packages/django/db/utils.py”, line 91, in exit
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - The above exception was the direct cause of the following exception:
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - Traceback (most recent call last):
Nov 18 21:46:10 <30>1 2024-11-18T20:45:31Z ip-xxx yyy-zzz - django.db.utils.DataError: interval out of range
Nov 18 21:46:10 <30>1 2024-11-18T20:45:45Z ip-xxx yyy-zzz - [2024-11-18 20:45:45 +0000] [40] [DEBUG] > PING bf 14 91 dc [binary, 4 bytes]
Nov 18 21:46:10 <30>1 2024-11-18T20:45:46Z ip-xxx yyy-zzz - [2024-11-18 20:45:46 +0000] [40] [DEBUG] > PING d3 68 11 37 [binary, 4 bytes]
Nov 18 21:46:10 <30>1 2024-11-18T20:46:05Z ip-xxx yyy-zzz - [2024-11-18 20:46:05 +0000] [40] [DEBUG] > PING 10 9b 95 21 [binary, 4 bytes]
Nov 18 21:46:10 <30>1 2024-11-18T20:46:07Z ip-xxx yyy-zzz - [2024-11-18 20:46:07 +0000] [40] [DEBUG] > PING a1 92 d5 1d [binary, 4 bytes]
Nov 18 21:46:20 - 172.18.0.1 - - [18/Nov/2024:20:46:20 +0000] “GET /_health HTTP/1.1” 200 172274 “-” “Mozilla (CloudronHealth)”

[petrs]

Hi @gabrielle,

there seems to be some “django.db.utils.DataError: interval out of range” error in the log. Do you use intervals somewhere (like formulas)?

You will probably need to find the real cause of the problem first before we can help you or fix it on our side. I recommend making a copy of the database (for instance using the new export/import feature) and step by step remove different fields, formula etc. and notice when and where the problem occurs or what makes it go away.

Unless you are willing to export and share your database privately with us I don’t think we can help here.

Alternatively you could set up a Sentry account for your baserow and give us access to see the problems reported there (they will have more details than a log like you posted).

[gabrielle]

Hi @petrs,

Thank you for your reply! I use plenty of formulas. What do you mean exactly by “intervals”?

I’ll try making a copy of the base to see if I can figure out the issue, if that fails I’ll set up a Sentry account and if that fails, I’ll share it with you privately.

[gabrielle]

I tried duplicating the base but got an error, same when trying to create a snapshot.
I ended up being able to export the workspace and find the field that was causing the issue preventing me from adding rows.

Now, I’ve added 20k rows to another table. It uploaded fine and I could edit a couple of records. As soon as I refreshed, I got the “View not found” error message. Seems like I can’t access that table again. I can see it from the navigation panel on the left, I can access the records content when they are linked to other records in other tables.

I ended up playing with the URL of the table so I could access it through a view that had no issue. Would you consider changing the error message and offer the user the possibility to access the table through another view if the one last accessed (and linked to the left navigation panel) is broken?

[gabrielle]

Hi @petrs,

I keep having issues with views that crash as soon as I add filters or try to group by fields.
Are there limits I should be aware of?
Also, I’ve been trying to update to 1.29.2 but keep getting the following error in the log:

Nov 21 00:10:34 box:docker pullImage error cloudron/io.baserow.cloudronapp:202411190118030000: failed to register layer: write /usr/local/share/.cache/yarn/v6/npm-@esbuild-linux-riscv64-0.18.20-6628389f210123d8b4743045af8caa7d4ddfc7a6-integrity/node_modules/@esbuild/linux-riscv64/bin/esbuild: no space left on device

Which is odd as I have 4+ Go of space left…

Any suggestions of things I should do to get Baserow to run smoothly?

[gabrielle]

There are about 2/3 of a table data I can’t access (lines become white and unclickable after 8k records). When I try exporting the view in csv, I get a server error saying:
ValueError: year 22024 is out of range

How can I fix it?

[petrs]

@gabrielle

What do you mean exactly by “intervals”?

Interval data type in PostgreSQL probably that can be a result of manipulating date times. Your last error ValueError: year 22024 is out of range also indicate that you have a problem with some date calculations. This might be a bug in Baserow as normally when there is an error in say formula we should just mark the formula as broken. But I don’t know enough about your database to pinpoint the issue.

Would you consider changing the error message and offer the user the possibility to access the table through another view if the one last accessed (and linked to the left navigation panel) is broken?

Yes this error is not very good and I have seen it many times on errors that have nothing to do with “View not found”. I will create an issue for that.

Nov 21 00:10:34 box:docker pullImage error cloudron/io.baserow.cloudronapp:202411190118030000: failed to register layer: write /usr/local/share/.cache/yarn/v6/npm-@esbuild-linux-riscv64-0.18.20-6628389f210123d8b4743045af8caa7d4ddfc7a6-integrity/node_modules/@esbuild/linux-riscv64/bin/esbuild: no space left on device

Not sure about this. But reading about your other errors it does seem that your deployed Baserow is having some deployment issues or multiple problems (perhaps it is not deployed right + you have some issues with formulas and date times). Unfortuntaly I don’t know how to help you here.

[petrs]

I created an issue here to make the error visible: View not found error covers the real issue (#3231) · Issues · Baserow / baserow · GitLab