Delete row returning 502 bad getaway

Are you using our SaaS platform (Baserow.io) or self-hosting Baserow?

SaaS

What are the exact steps to reproduce this issue?

I configured a delete as column of the grid and the event to me looks correct. what is wrong here?
i can not understand it honestly. both claude opus 4.8 and kuma (gpt-4) are not helpful.
the 502 error does not look to be my fault (?)

Attach screenshots, videos, or logs that demonstrate the issue.

Hello @Lorenzo,

Please accept my apologies for the inconvenience, we are investigating this at the moment. I’ll report back here when it’s resolved.

Cheers,

Peter

i forgot to mention that the record is actually deleted despite the operation request returning 502. bc of the error the grid is not reloaded (f5 will ask for the login again). the only thing that works is changing page (or view as you call it here)

Hello @Lorenzo, I’ve had the same error: Bug when deleting rows and updating rows with files

In my case, an error also appeared when updating rows that contain files.

Thanks, @picklepete, for the support!

Good morning @Lorenzo and @khalil.io,

Some good news: I can confirm that the row deletion is a bug, but it’s isolated to just the application builder, it still works in automations. The action does still delete the row, but an error pop-up is shown, which is inaccurate.

The bad news: a fix today is unlikely, we will need to investigate this deeper early next week.

Please accept my apologies for the inconvenience, we’ll hopefully have it resolved very soon.

Cheers,

Peter

hey @picklepete how are the fixes going? have you (or Claude :wink:) started the fixing session?
can we still expect a fix early this week?

thanks!

Hi @Lorenzo,

It’s fixed and awaiting deployment, which should hopefully happen tomorrow. Thanks again for your patience, I hope it hasn’t caused too much inconvenience!

Cheers,

Peter

I’m sorry to bother you @picklepete , i would like to know about the fix and if the publish of it could be causing:


Thanks in advance,
Lorenzo

Hi @Lorenzo!

That’s a strange one! A fix for the delete row action was deployed yesterday.

Would you mind opening your developer tools console (e.g. in Chrome: View → Developer → Developer Tools) and screenshotting the request which failed? Like this:

It’s possible that it’s unrelated to the delete row issue, but we’ll see!

Cheers,

Peter

Totally right:


these are all the network requests from the opening of the publish popup to the end of the publish. as you can see no errors here but in the console i have, per try, this error:

Uncaught (in promise) TypeError: this.$el.querySelector is not a function
    at Proxy.focusOnError (error.js:67:30)
    at Proxy.<anonymous> (error.js:57:33)

i hope this can help, might it be a case of: fixed a bug → created a bug? :laughing:

good luck on this!

Thanks @Lorenzo,

Judging by that screenshot, it looks like the publish (the async one, second from the top) was successful. Can you confirm by looking at the published application if it looks right?

If it has been published correctly, this is a frontend issue, unrelated to the delete-row issue, which we can also investigate.

Cheers,

Peter

sorry for not having mentioned it, but the deploy actually fails. the modifications applied to the project are not being reflected in the published version.

Cheers,
Lorenzo

No problem at all! Would you mind publishing again with the Network tab open, and when you see the async/ request, sending me a screenshot like this?

That Response tab should shed more light on what your issue is, unfortunately at the moment I don’t have many clues!

Cheers,

Peter

here it is:

let me know if i can help in any other way

Grazie! And one more: if you open the jobs/?job_ids=707363 (just before the last entry), what does that Response tab show?

Cheers,

Peter

I’m sorry, i had to redo the publish:


this is the response of the last https://api.baserow.io/api/jobs/?job_ids=707371
```json
{
“jobs”: [
{
“id”: 707371,
“type”: “publish_domain”,
“progress_percentage”: 100,
“state”: “failed”,
“human_readable_error”: “Something went wrong during the publish_domain job execution.”,
“created_on”: “2026-06-24T13:33:50.346387Z”,
“updated_on”: “2026-06-24T13:34:02.337028Z”
}
]
}
```

all the other requests have the same data except for the “progress_percentage” value that increases and the “human_readable_error” that is populated only in the last request.

Thank you @Lorenzo! I can see, using 707371, that your issue is to do with a formula.

Have you recently editted formula where you’ve put a $ symbol into it? If you could share where that is, and what element it’s used by, that’d be great!

Cheers,

Peter

Hey @Lorenzo, I can see the problem.

You have a formula somewhere that goes: $formula: [form data]. This is a bug introduced by Kuma when it assisted you at some point. If you manually remove the $formula: prefix, it’ll publish. We’ll work on addressing the Kuma part soon.

Cheers,

Peter

ok, thanks, i will check and try to locate the formula. do not know at the moment where it could be located at.

you surely have to address kuma, it hallucinates a lot and 7/10 times does not answer and asks for a new session, cool idea in theory, unfortunate result.
it would be really helpful if it worked better. Can i also suggest an MCP?
ps: i know the main driver for gpt 4 models is cost, are you trying internally run AI?

have a wonderful day
Lorenzo

EDIT:
I can not find where the modification was made: kuma touched only 1 page and only 1 input in it. i verified it and it looks good to me, i tried also to reassign the value to the field. no success.

EDIT 2:
would you be open for a google meet call to try resolving this issue? if not it’s fine and thanks for all the work you’re doing for me :smiley:

I totally agree, my apologies for any inconvenience! We definitely want to iterate on Kuma’s abilities, every few releases it gets new superpowers :grimacing:

We already support an MCP server :rocket:

The model selection for Kuma has to juggle a few criteria, and cost / performance are careful things to dial in.

I’m very sorry, but not at the moment! If you click around data sources / elements / workflow actions, one of them will have a $formula prefix to it.

Cheers,

Peter