What are the specs of the service or server you are using to host Baserow.
8+ GBs of ram, AMD64 (amd milan series)
Which version of Baserow are you using.
1.26.1
How have you configured your self-hosted installation?
issue seen on default config as well as non-standard ones.
Describe the problem
Apparently, certain airtable imports result in problematic batches of specific cells in specific columns. When present - attempts to duplicate or filter by that value result in errors: for duplicate: “unkonwn error”
filters for (is / is not) just ignore these vales.
contain filters seem to observe these values.
copy-paste is possible and does not yield errors.
I have narrowed it down, in one table, to a few problematic single select columns.
Deleting the values in the problematic cells seems to solve the problem. However, one would have to check every row one by one to know for sure if a table is affected or not…
Describe, step by step, how to reproduce the error or problem you are encountering.
Not able to reproduce the issue directly - may be Airtable base/import dependent (repeated import of the particular base from Airtable did not lead to this error). However, once the issue is there - it is consistent. (duplicated tables inherit this error if the original one had it).
How many rows in total do you have in your Baserow tables?
this particular table has 15 thousand rows, but issue present for tables “trimmed down” to 20 rows too.
Please attach full logs from all of Baserow’s services
this is what pops up right after duplication attempt:
[BACKEND][2024-08-09 09:24:23] WARNING 2024-08-09 16:24:23,011 django.request.log_response:241- Bad Request: /api/database/rows/table/877/batch/
filters do not yield any error messages.
it’s very likely related to some bug during the import from Airtable, but unfortunately, I’m unable to reproduce the issue on my local setup, which makes it challenging to identify the exact cause.
To help us investigate further, could you please provide more details on how to reproduce the issue?
This is likely a separate issue, as the other table was not imported via Airtable.
Getting back to this one - it was imported about 3 month ago. Since then, the original airtable base has been changed a bit and apparenlty, importing it no longer results in a faulty Baserow table.
The issue presented here has been discovered relatively recently. Is there a chance this is related to a bug which has been fixed since the time the table was imported?
Is there a way I could share the contents of the impacted Baserow table for you to investigate further?
I’m working on a few other bugs reported to me by my team - if I’m able to reproduce this issue after Airtable current import - I’ll surely share the Airtable link.
If you imported your table before that date, the bug you’re seeing is very likely caused
by the linked issue.
The MR fixed the issue with the import from Airtable, but unfortunately, it didn’t fix the already imported tables.
Is there a way I could share the contents of the impacted Baserow table for you to investigate further?
One way to export the data is to use the export_workspace_applications Django management command from the command line interface (CLI). You can then send us both the generated .json and .zip files. However, because the table might be malformed, I am unsure if this approach will work in this situation.
If you attempt to set the same option in the filter, you should see the exact same ID. If not, it indicates that the option IDs were not imported correctly during the import process, confirming that this issue is causing the faulty behavior.
@davide
can you confirm that this bug fix also covers the issue “deleting one column deletes (faulty) values in another column”? - the one shown in the video.
