Serialize_rows_value function used as key in dict lookup, does this look correct ? baserow/contrib/database/ws/rows/signals.py:71

I am running into an issue with PATCH requests on rows with my custom plugin. The sentry stack trace is here:

This issue is coming up as I’m upgrading my plugin from baserow 1.19.1 to 1.26.1.

I’m probably going to have to do some digging myself and perhaps debug. But I’d like some help understanding the intention of the code at baserow/contrib/database/ws/rows/signals.py:71:

@receiver(row_signals.rows_updated)
def rows_updated(
    sender,
    rows,
    user,
    table,
    model,
    before_return,
    updated_field_ids,
    **kwargs,
):
    table_page_type = page_registry.get("table")
    before_rows_values = dict(before_return)[serialize_rows_values]
    transaction.on_commit(
        lambda: table_page_type.broadcast(
            RealtimeRowMessages.rows_updated(
                table_id=table.id,
                serialized_rows_before_update=before_rows_values,
                serialized_rows=get_row_serializer_class(
                    model, RowSerializer, is_response=True
                )(rows, many=True).data,
                metadata=row_metadata_registry.generate_and_merge_metadata_for_rows(
                    user, table, [row.id for row in rows]
                ),
            ),
            getattr(user, "web_socket_id", None),
            table_id=table.id,
        )
    )

am I understand correctly that this code is looking up the value for key “serialize_rows_value (the function)?” ? Wouldn’t it make more sense to have:
before_rows_values = dict(before_return)[serialize_rows_values()]
right now, the function is not found as a key in the dict, and hence the KeyError exception.

I’m simply not understanding the intention here. @bram maybe you can help understand the intention of the code ?

It’s entirely possible that the serialization code for my custom field in my plugin is incorrect.

The custom field type in involved is LanguageField here:

I’m not expecting anyone to fully resolve this but I’d like a few pointers on where to look, I can do the deep dive debugging myself.

Hello @lucw ,

the intention here is to use the dictionary returned by before_rows_update.send where we serialized the values of the rows before updating them.

We cannot call the function here because the rows have already been updated at this point.

I cannot quickly find the MR, but we had a similar problem in the past where sentry wrapped the function in a way that made this approach fail.

Weirdly, we’re not seeing the same issue. Are you running different versions of the dependencies, maybe?

I’d suggest looking into Sentry or other libraries that might wrap that function, making that line to fail.

I think that’s exactly what’s happening, sentry is somehow interfering here. Do you have any more details ? i’m going to be debugging.

short version:
need the following setting in sentry init:

integrations=[DjangoIntegration(signals_spans=False, middleware_spans=False)],

Baserow does have this setting in it’s sentry setup. Thank you so much @davide for putting me on the right track.

long version:
I started my plugin in mid-2022 and I believe baserow didn’t have sentry support out of the box at that time. So I I hacked together the sentry setup by maintaining a set of patches which I apply on baserow at plugin install time. So essentially I had my own sentry setup and I didn’t benefit from the baserow settings.

For now i’m probably going to be keeping my custom setup, because baserow tends to spam transactions and filling up my sentry quota.

I love baserow !!

Thank you, @lucw, for your enthusiasm and kind words! We’re committed to making Baserow the best it can be, and receiving messages like yours is truly appreciated. :pray: