'discourse remap' should fail noisily and mightily when an error occurs

Contribute Bug

AI-generated summary

A discussion is underway regarding the ideal behavior of discourse remap when an error occurs. supermathie reported an instance where the remap process encountered a deadlock error but continued partially, leaving the user unaware of the issue. sam suggested that instead of retrying, the process should abort and print a message indicating that the remap was only partially applied, prompting the user to re-run the remap. sam reassigned the task to Osama, who has implemented the suggested behavior via pull request #6005 on GitHub.

1

had this happen in the middle of a remap:

…
Remapping posts raw
1454 rows affected!
Remapping posts cooked
Error: ERROR:  deadlock detected
DETAIL:  Process 10050 waits for ShareLock on transaction 552065959; blocked by process 9965.
Process 9965 waits for ShareLock on transaction 552065918; blocked by process 10050.
HINT:  See server log for query details.
CONTEXT:  while rechecking updated tuple (59101,9) in relation "posts"
Remapping posts edit_reason
0 rows affected!
Remapping posts raw_email
4340 rows affected!
Remapping posts action_code
0 rows affected!
Remapping posts image_url
122356 rows affected!
…continues…

Good thing I was watching it or I wouldn’t have known!

Expected behaviour: discourse remap should retry and abort the entire process if it cannot succeed

8 Likes
3

I want to get this sorted, but it feels to me like this would require an enormous transaction which would totally lock up the database.

Instead lets just get some basics here first:

On first failure, abort and print a message saying it was only partially applied asking users to re-run the remap.

@supermathie does that work for you? @zogstrip do you mind if I reassign this to @Osama ?

2 Likes
4

Not at all :ok_hand:

2 Likes
6

This is done via: :candy:

https://github.com/discourse/discourse/pull/6005

9 Likes