Interesting error in Redash v10 after migration

Development
1

Came across an interesting error with a migrated (to Redash v10) instance tonight.

A customer was trying to delete one of the migrated users, with the user still in the “Pending invitation” state.

However, the delete wasn’t working. On screen it was just showing “Internal server error” (at which point they reached out to me).

Looking at the server logs when triggering the error gave what looks like a smoking gun type of thing:

postgres_1  | 2021-11-08 11:46:09.282 UTC [129297] ERROR:  null value in column "user_id" of relation "favorites" violates not-null constraint
postgres_1  | 2021-11-08 11:46:09.282 UTC [129297] DETAIL:  Failing row contains (2021-11-08 11:46:09.258622+00, 2021-11-06 05:40:10.061985+00, 9, 1, Dashboard, 9, null).
postgres_1  | 2021-11-08 11:46:09.282 UTC [129297] STATEMENT:  UPDATE favorites SET updated_at=now(), user_id=NULL WHERE favorites.id = 9
postgres_1  | 2021-11-08 11:46:20.532 UTC [129456] ERROR:  null value in column "user_id" of relation "changes" violates not-null constraint
postgres_1  | 2021-11-08 11:46:20.532 UTC [129456] DETAIL:  Failing row contains (queries, 1, 1, 1, null, {"query": {"previous": "SELECT DATE_FORMAT(trans_date, \"%Y-%m-%..., 2021-11-06 05:34:26.160611+00).
postgres_1  | 2021-11-08 11:46:20.532 UTC [129456] STATEMENT:  UPDATE changes SET user_id=NULL WHERE changes.id = 1

From reading that, what seems to be happening is that migrated users can have more information (eg favourites, etc) than normal pending users.

So, the “DELETE” action for normal pending users doesn’t quite work for them, as there looks to be a referential integrity CASCADE which then goes badly when it tries to set a NULL user_id for things.

Normal pending users won’t have ever logged in, so don’t have any favourites (etc) to muck things up.

The workaround in this instance was to just disable those users instead of deleting them. The “proper” fix might be to have the backend understand the difference between new pending-invitation users and migrated pending-invitation ones, and display a “DISABLE” button instead of “DELETE” for the migration ones. Not sure yet…

Anyone have thoughts? :slight_smile:

2

This is expected behaviour. In fact, if you check the origin instance you’ll see that these users can’t be deleted either: only disabled.

Redash only allows deletion of pending users that have no objects assigned to them. If you invited a user and they never logged-in then you can delete them completely. But if they ever logged-in, or received objects through a migration, then the option name changes from “Delete User” to “Disable User”.

Of course an admin can go directly to the database to delete a user using SQL, and take care of the cascading foreign keys dependency.

3

Thanks Jesse, that makes sense. :smile: