Can't update specific columns

Hi, I’m new here I hope this is the right place. I’m using Baserow with an organization and we have some tables where some time we can’t update or edit specific columns.

We tried everything and the only solution we found is to create a new column and copy all the content inside (but even after that, some time and it breaks again).
Can you help us understand what’s happening?

Here are some logs:

Summary

eived
[BACKEND][2023-08-14 17:47:26] 413|2023-08-14 17:47:26.217|INFO|baserow.core.action.signals:log_action_receiver:28 - do: workspace=15 action_type=update_field user=1
[BACKEND][2023-08-14 17:47:26] 172.17.0.1:0 - “PATCH /api/database/fields/6422/ HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:26] 172.17.0.1:0 - “GET /api/database/views/grid/2585/?count=true HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:26] 172.17.0.1:0 - “GET /api/database/views/grid/2585/?count=true HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:26] 172.17.0.1:0 - “GET /api/database/views/grid/2585/?limit=120&offset=0&include=row_metadata HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:26] 172.17.0.1:0 - “GET /api/database/views/grid/2585/?limit=120&offset=0&include=row_metadata HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:26] 172.17.0.1:0 - “GET /api/database/views/grid/2585/aggregations/ HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:29] 172.17.0.1:0 - “GET /api/database/views/grid/2585/aggregations/ HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:29] 172.17.0.1:0 - “GET /api/database/views/table/664/?include=filters,sortings,decorations HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:29] 172.17.0.1:0 - “GET /api/database/fields/table/664/ HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:29] 172.17.0.1:0 - “GET /api/database/views/grid/2592/?limit=80&offset=0&include=field_options%2Crow_metadata HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:32] 127.0.0.1:38072 - “GET /api/_health/ HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:36] 127.0.0.1:38086 - “GET /api/_health/ HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:36] 172.17.0.1:0 - “GET /api/database/views/table/663/?include=filters,sortings,decorations HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:36] 172.17.0.1:0 - “GET /api/database/fields/table/663/ HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:37] 172.17.0.1:0 - “GET /api/database/views/grid/2585/?limit=80&offset=0&include=field_options%2Crow_metadata HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:41] 172.17.0.1:0 - “GET /api/database/views/grid/2585/aggregations/ HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:41] 172.17.0.1:0 - “GET /api/database/fields/table/664/ HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:41] 172.17.0.1:0 - “GET /api/database/rows/table/664/?page=1&size=10 HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:42] 172.17.0.1:0 - “GET /api/database/views/table/664/?limit=1&type=grid HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:44] 172.17.0.1:0 - “GET /api/database/views/2592/field-options/ HTTP/1.1” 200
[BACKEND][2023-08-14 17:47:44] ERROR 2023-08-14 17:47:44,368 django.request.log_response:224- Internal Server Error: /api/database/rows/table/663/205/
[BACKEND][2023-08-14 17:47:44] Traceback (most recent call last):
[BACKEND][2023-08-14 17:47:44] File “/baserow/venv/lib/python3.9/site-packages/asgiref/sync.py”, line 486, in thread_handler
[BACKEND][2023-08-14 17:47:44] raise exc_info[1]
[BACKEND][2023-08-14 17:47:44] File “/baserow/venv/lib/python3.9/site-packages/django/core/handlers/exception.py”, line 38, in inner
[BACKEND][2023-08-14 17:47:44] response = await get_response(request)
[BACKEND][2023-08-14 17:47:44] File “/baserow/venv/lib/python3.9/site-packages/django/core/handlers/base.py”, line 233, in _get_response_async
[BACKEND][2023-08-14 17:47:44] response = await wrapped_callback(request, *callback_args, **callback_kwargs)
[BACKEND][2023-08-14 17:47:44] File “/baserow/venv/lib/python3.9/site-packages/asgiref/sync.py”, line 448, in call
[BACKEND][2023-08-14 17:47:44] ret = await asyncio.wait_for(future, timeout=None)
[BACKEND][2023-08-14 17:47:44] File “/usr/lib/python3.9/asyncio/tasks.py”, line 442, in wait_for
[BACKEND][2023-08-14 17:47:44] return await fut
[BACKEND][2023-08-14 17:47:44] File “/baserow/venv/lib/python3.9/site-packages/asgiref/current_thread_executor.py”, line 22, in run
[BACKEND][2023-08-14 17:47:44] result = self.fn(*self.args, **self.kwargs)
[BACKEND][2023-08-14 17:47:44] File “/baserow/venv/lib/python3.9/site-packages/asgiref/sync.py”, line 490, in thread_ha

And a recording:
(I can’t upload it since I’m a new user)

Steps to reproduce:

  1. select a field
  2. try adding some item already present in another table
  3. the item appears and then disappears

Thank you very much

Hello @Mirko, you should now be able to add attachments. :raised_hands:

1 Like

Hey @Mirko, we are having difficulty assisting you with your request because we need more information to investigate the issue. Please provide all necessary details as outlined in this template: *READ ME FIRST* Technical Help FAQs - #2 by nigel . Thank you. :slightly_smiling_face:

Specifically we really need to see exactly what your table schema is (what fields, what formulas) and also need to see that full log as you’ve cut off the exception half way through.

@nigel @olgatrykush

Here are PrivateBin links to requested texts:

Point 1: Baserow Version and Installation Method: PrivateBin (PSW: bsbug)

Point 2: VPS Infos: PrivateBin (PSW: bsbug)

Point 3: Baserow API Version: PrivateBin (PSW: bsbug)

Point 4: Environment Configuration: PrivateBin (PSW: bsbug)

Point 5: Start Server Command: PrivateBin (PSW: bsbug)

ERROR LOG: Bug error log: PrivateBin (PSW: bsbug)

Please note that links will expire in less than 3 days.

Also, I attached a detailed screencast to demonstrate the issue.

If you cannot see the screencast, I’ve uploaded it here: https://file.io/4w2fvFmNu24x

@nigel @olgatrykush any news?

Hey @Mirko , I think I have enough information to try and replicate, i’ll get to it this afternoon. From the stack traces it looks specifically the part that sends realtime signals to any publicly visible views is crashing, so one possible workaround (not a great one, we’ll fix this) is to turn off any publicly shared views for that table, and that might let you edit those columns again.

Hi @Mirko , i’ve identified the exact cause of the bug, my previous advice about it being related to publicly shared views was incorrect and I don’t believe the work around mentioned above will help.

We will fix for the next version of Baserow being released in Sept.

An updated work around until you upgrade is as follows:

  1. Imagine you have three Baserow tables A, B and C
  2. The bug is triggered when you have a lookup field or formula with the lookup function in table A, which lookups up a link row field in table B, which links table B and C.
  3. For now, you can instead create a lookup in table B, which looks up the primary field in table C.
  4. Now in table A, instead of looking up a link row field in table B, look up the new lookup field you made in table B.
  5. The end result should be functionally the same, however now your link row fields should start working.

There might be other ways of triggering this bug so please let me know if you don’t think the above applied to you, but i’ve found the root cause and should be able to fix all of them in one go.