Hey there,
I’m having an issue moving posts on my self-hosted instance (v.3.4.0.beta3-dev)
I checked my reactions plugin, and it’s up-to-date (seeing 500 Error: There was an error moving posts ).
Is there any recommended fix for such issue (or more details on the source)?
Thanks in advance,
Marc
Moin
December 12, 2024, 2:15pm
2
Mustachian Post:
.3.4.0.beta3-dev
When did you last update?
There were two fixes this week. The last one was merged yesterday.
discourse:main
← discourse:pento/fix-moving-posts-to-topic-chronologically
opened 03:01AM - 09 Dec 24 UTC
## ✨ What's This?
When moving posts to an existing topic whilst preserving ch… ronological ordering, the second chunk of posts moved can trigger a PostgreSQL error:
```
PG::UniqueViolation (ERROR: duplicate key value violates unique constraint "post_timings_unique"
DETAIL: Key (topic_id, post_number, user_id)=(36, 29, 1) already exists.
)
lib/mini_sql_multisite_connection.rb:109:in `run'
app/models/post_mover.rb:432:in `copy_shifted_post_timings_from_temp'
app/models/post_mover.rb:118:in `handle_moved_references'
app/models/post_mover.rb:94:in `move_posts_to'
app/models/post_mover.rb:28:in `block in to_topic'
app/models/post_mover.rb:28:in `to_topic'
```
The cause of this error is a little bit silly.
After a post has been moved from a different topic, a moderator post is inserted into the old topic, pointing to where the post has been moved to.
This moderator post is ultimately created using `PostCreator`, which by default, records a 5000ms Post Timing for that newly created post. Because of how Post Timings are tracked, this timing will be inserted into the `post_timings` table with the same `topic_id`, `post_number`, and `user_id` as the moved post used to have before it was moved.
Now, when we proceed to moving the next post, `PostMover.move_post_timings` will look for post timings to move based on whether there's a corresponding entry in the `moved_posts` table. This is where our problem lays: the post that we previously moved has an entry in the `moved_posts` table, but now there's an unexpected entry in `post_timings` that we know doesn't belong to the previously moved post, but it has matching `topic_id`, `post_number`, and `user_id` of the what that moved post used to have, anyway.
To fix this, we can enforce only matching post IDs that are being moved in this run of `PostMover`.
Internal ref t/142010/5
## 👑 Testing
The simplest way to reproduce this error is:
- Create a destination topic.
- Create the first source topic, and add a reply to it.
- Create a second source topic, and add a reply to it.
- Move the reply in the second source topic to the destination topic, remembering to check the “preserve chronological order” option.
- Move the reply in the first source topic to the destination, again checking the “preserve chronological order” option.
discourse:main
← discourse:pento/fix-moving-first-posts-to-topic-chronologically
opened 03:13AM - 11 Dec 24 UTC
## ✨ What's This?
This is a follow-up to #30176.
When moving multiple firs… t posts to an existing topic whilst preserving chronological ordering, the second move can trigger a PostgreSQL error:
```
PG::UniqueViolation:
ERROR: duplicate key value violates unique constraint "post_timings_unique"
DETAIL: Key (topic_id, post_number, user_id)=(1278, 2, 2261) already exists.
# ./lib/mini_sql_multisite_connection.rb:109:in `run'
# ./app/models/post_mover.rb:478:in `copy_shifted_post_timings_from_temp'
# ./app/models/post_mover.rb:137:in `handle_moved_references'
# ./app/models/post_mover.rb:108:in `move_posts_to'
# ./app/models/post_mover.rb:35:in `block in to_topic'
# ./app/models/post_mover.rb:35:in `to_topic'
# ./app/models/topic.rb:1308:in `move_posts'
```
Additionally, if you move from the same topic to a newer destination: it will fail with this error:
```
PG::CardinalityViolation:
ERROR: ON CONFLICT DO UPDATE command cannot affect row a second time
HINT: Ensure that no rows proposed for insertion within the same command have duplicate constrained values.
# ./lib/mini_sql_multisite_connection.rb:109:in `run'
# ./app/models/post_mover.rb:488:in `copy_first_post_timings'
# ./app/models/post_mover.rb:139:in `handle_moved_references'
# ./app/models/post_mover.rb:108:in `move_posts_to'
# ./app/models/post_mover.rb:35:in `block in to_topic'
# ./app/models/post_mover.rb:35:in `to_topic'
# ./app/models/topic.rb:1308:in `move_posts'
```
Both of these issues can be fixed using the same approach as in #30176: ensuring we only copy post timings for the specific posts that are being moved.
Internal ref t/142010/15
## 👑 Testing
The first error can be reproduced using this method:
- Create two source topics with no replies to either.
- Create a destination topic.
- Move the single post in the second topic to the destination.
- Move the single post in the first topic to the destination.
The second error can be reproduced with this method:
- Create a source topic, and add a reply to it.
- Create a destination topic.
- Move the reply in the source topic to the destination topic, remembering to check the “preserve chronological order” option.
- Move the first post in the source topic to the destination, again checking the “preserve chronological order” option.
2 Likes
Few weeks back. I just updated, and it fixed the issue
Thanks for the fast support, topic can be closed.
2 Likes